Re: [PATCH] firmware: ti_sci: refactor deprecated strncpy
On 21:03-20230914, Kees Cook wrote: > On Wed, Sep 13, 2023 at 08:23:02PM +, Justin Stitt wrote: > > `strncpy` is deprecated for use on NUL-terminated destination strings [1]. > > > > We should prefer more robust and less ambiguous string interfaces. > > > > A suitable replacement is `strscpy` [2] due to the fact that it guarantees > > NUL-termination on the destination buffer. > > > > It does not seem like `ver->firmware_description` requires NUL-padding > > (which is a behavior that strncpy provides) but if it does let's opt for > > `strscpy_pad()`. > > > > Link: > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > > [1] > > Link: > > https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > > Link: https://github.com/KSPP/linux/issues/90 > > Cc: linux-harden...@vger.kernel.org > > Signed-off-by: Justin Stitt > > Looks right to me. > > Reviewed-by: Kees Cook Does this belong to stable as well? If so, please add appropriate stable process. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to json schema
On 10:32-20210420, Jens Wiklander wrote: [...] > > diff --git > > a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > > b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > > new file mode 100644 > > index ..6513b5ac8b2c > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml > > @@ -0,0 +1,62 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > Are these links supposed to work? I have'nt seen any of them work.. and I think it was intentional. I am guessing that someday, eventually it might, typically the path beyond devicetree.org is either in [1] or [2]. [1] https://github.com/devicetree-org/dt-schema [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
Stephen, On 07:51-20210417, Nishanth Menon wrote: > On 16:55-20210416, Stephen Boyd wrote: > > Quoting Nishanth Menon (2021-04-15 23:37:19) > > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > > b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > > new file mode 100644 > > > index ..72633651f0c7 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > > @@ -0,0 +1,52 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: TI-SCI clock controller node bindings > > > + > > > +maintainers: > > > + - Nishanth Menon > > > + > > > +allOf: > > > + - $ref: /schemas/clock/clock.yaml# > > > > Is this needed? > > https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml > This standardizes provider properties like '#clock-cells' etc, allowing > you to add more stricter checks or controls in the future if necessary. > > while: > > https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml > is more a consumer node description. > > Should I have picked a different yaml as base for a standard clock-controller > base? > Thinking again, I think your comment was to drop the clock.yaml inclusion, and, as a result this schema can become more stringent.. Could you clarify? > > > > > + > > > +description: | > > > + Some TI SoCs contain a system controller (like the Power Management > > > Micro > > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for > > > controlling > > > + the state of the various hardware modules present on the SoC. > > > Communication > > > + between the host processor running an OS and the system controller > > > happens > > > + through a protocol called TI System Control Interface (TI-SCI > > > protocol). > > > + > > > + This clock controller node uses the TI SCI protocol to perform various > > > clock > > > + management of various hardware modules (devices) present on the SoC. > > > This > > > + node must be a child node of the associated TI-SCI system controller > > > node. > > > + > > > +properties: > > > + $nodename: > > > +pattern: "^clock-controller$" > > > > Is this nodename pattern check required? > > I'd like the definition on rails and not subject to interpretation, and > restrict the kind of subnodes under TISCI controller node. > > > > > > + > > > + compatible: > > > +const: ti,k2g-sci-clk > > > > I thought most things keyed off the compatible string. > > Yes, they are. I am not sure I understand your question here. Did you > mean to indicate that having $nodename and compatible both are > redundant? > > Redundancy was'nt the intent of this schema definition, rather, I'd like > to make sure that it is not upto interpretation or debate as to what the > node name should be: I believe clock-controller is the correct nodename > (without @0x... since this does'nt use reg property) instead of using > clocks, tisci-clock as the node names. > > > Do you suggest something different? > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
On 16:55-20210416, Stephen Boyd wrote: > Quoting Nishanth Menon (2021-04-15 23:37:19) > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > new file mode 100644 > > index ..72633651f0c7 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml > > @@ -0,0 +1,52 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: TI-SCI clock controller node bindings > > + > > +maintainers: > > + - Nishanth Menon > > + > > +allOf: > > + - $ref: /schemas/clock/clock.yaml# > > Is this needed? https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml This standardizes provider properties like '#clock-cells' etc, allowing you to add more stricter checks or controls in the future if necessary. while: https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml is more a consumer node description. Should I have picked a different yaml as base for a standard clock-controller base? > > > + > > +description: | > > + Some TI SoCs contain a system controller (like the Power Management Micro > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for > > controlling > > + the state of the various hardware modules present on the SoC. > > Communication > > + between the host processor running an OS and the system controller > > happens > > + through a protocol called TI System Control Interface (TI-SCI protocol). > > + > > + This clock controller node uses the TI SCI protocol to perform various > > clock > > + management of various hardware modules (devices) present on the SoC. This > > + node must be a child node of the associated TI-SCI system controller > > node. > > + > > +properties: > > + $nodename: > > +pattern: "^clock-controller$" > > Is this nodename pattern check required? I'd like the definition on rails and not subject to interpretation, and restrict the kind of subnodes under TISCI controller node. > > > + > > + compatible: > > +const: ti,k2g-sci-clk > > I thought most things keyed off the compatible string. Yes, they are. I am not sure I understand your question here. Did you mean to indicate that having $nodename and compatible both are redundant? Redundancy was'nt the intent of this schema definition, rather, I'd like to make sure that it is not upto interpretation or debate as to what the node name should be: I believe clock-controller is the correct nodename (without @0x... since this does'nt use reg property) instead of using clocks, tisci-clock as the node names. Do you suggest something different? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] dt-bindings: arm: firmware: Convert linaro,optee-tz to json schema
Convert linaro,optee-tz to json schema format for better documentation
and error checks.
NOTE:
1. This change does introduce a stricter naming convention for
optee nodes.
2. We do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon
---
.../bindings/arm/firmware/linaro,optee-tz.txt | 31 --
.../arm/firmware/linaro,optee-tz.yaml | 62 +++
2 files changed, 62 insertions(+), 31 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
create mode 100644
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
deleted file mode 100644
index d38834c67dff..
--- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-OP-TEE Device Tree Bindings
-
-OP-TEE is a piece of software using hardware features to provide a Trusted
-Execution Environment. The security can be provided with ARM TrustZone, but
-also by virtualization or a separate chip.
-
-We're using "linaro" as the first part of the compatible property for
-the reference implementation maintained by Linaro.
-
-* OP-TEE based on ARM TrustZone required properties:
-
-- compatible : should contain "linaro,optee-tz"
-
-- method : The method of calling the OP-TEE Trusted OS. Permitted
- values are:
-
- "smc" : SMC #0, with the register assignments specified
- in drivers/tee/optee/optee_smc.h
-
- "hvc" : HVC #0, with the register assignments specified
- in drivers/tee/optee/optee_smc.h
-
-
-
-Example:
- firmware {
- optee {
- compatible = "linaro,optee-tz";
- method = "smc";
- };
- };
diff --git
a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
new file mode 100644
index ..6513b5ac8b2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OP-TEE Device Tree Bindings
+
+maintainers:
+ - Jens Wiklander
+
+description: |
+ OP-TEE is a piece of software using hardware features to provide a Trusted
+ Execution Environment. The security can be provided with ARM TrustZone, but
+ also by virtualization or a separate chip.
+
+ We're using "linaro" as the first part of the compatible property for
+ the reference implementation maintained by Linaro.
+
+properties:
+ $nodename:
+const: 'optee'
+
+ compatible:
+const: linaro,optee-tz
+
+ method:
+description: The method of calling the OP-TEE Trusted OS.
+oneOf:
+ - description: |
+ SMC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+items:
+ - const: smc
+ - description: |
+ HVC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+items:
+ - const: hvc
+
+required:
+ - compatible
+ - method
+
+additionalProperties: false
+
+examples:
+ - |
+firmware {
+optee {
+compatible = "linaro,optee-tz";
+method = "smc";
+};
+};
+
+ - |
+firmware {
+optee {
+compatible = "linaro,optee-tz";
+method = "hvc";
+};
+};
--
2.31.0
[PATCH 1/4] dt-bindings: reset: Convert ti,sci-reset to json schema
Convert the ti,sci-reset to json schema for better checks and documentation.
Differences being:
- Drop consumer example as they are documented in the corresponding
bindings themselves.
- Drop phandle description for reset consumer or cell definition as it is
redundant.
NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon
---
.../bindings/reset/ti,sci-reset.txt | 62 ---
.../bindings/reset/ti,sci-reset.yaml | 51 +++
2 files changed, 51 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
deleted file mode 100644
index 8b1cf022f18a..
--- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Reset Controller
-=
-
-Some TI SoCs contain a system controller (like the Power Management Micro
-Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
-the state of the various hardware modules present on the SoC. Communication
-between the host processor running an OS and the system controller happens
-through a protocol called TI System Control Interface (TI-SCI protocol).
-For TI SCI details, please refer to the document,
-Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-TI-SCI Reset Controller Node
-
-This reset controller node uses the TI SCI protocol to perform the reset
-management of various hardware modules present on the SoC. Must be a child
-node of the associated TI-SCI system controller node.
-
-Required properties:
-
- - compatible : Should be "ti,sci-reset"
- - #reset-cells: Should be 2. Please see the reset consumer node below
for
- usage details.
-
-TI-SCI Reset Consumer Nodes
-===
-Each of the reset consumer nodes should have the following properties,
-in addition to their own properties.
-
-Required properties:
-
- - resets : A phandle and reset specifier pair, one pair for each reset
- signal that affects the device, or that the device manages.
- The phandle should point to the TI-SCI reset controller node,
- and the reset specifier should have 2 cell-values. The first
- cell should contain the device ID. The second cell should
- contain the reset mask value used by system controller.
- Please refer to the protocol documentation for these values
- to be used for different devices,
- http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
-common reset controller usage by consumers.
-
-Example:
-
-The following example demonstrates both a TI-SCI reset controller node and a
-consumer (a DSP device) on the 66AK2G SoC.
-
-pmmc: pmmc {
- compatible = "ti,k2g-sci";
-
- k2g_reset: reset-controller {
- compatible = "ti,sci-reset";
- #reset-cells = <2>;
- };
-};
-
-dsp0: dsp@1080 {
- ...
- resets = <_reset 0x0046 0x1>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
new file mode 100644
index ..4639d2cec557
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI reset controller node bindings
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ Some TI SoCs contain a system controller (like the Power Management Micro
+ Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for
controlling
+ the state of the various hardware modules present on the SoC. Communication
+ between the host processor running an OS and the system controller happens
+ through a protocol called TI System Control Interface (TI-SCI protocol).
+
+ This reset controller node uses the TI SCI protocol to perform the reset
+ management of various hardware modules present on the SoC. Must be a child
+ node of the associated TI-SCI system controller node.
+
+properties:
+ $nodename:
+pattern: "^reset-controller$"
+
+ compatible:
+const: ti,sci-reset
+
+ "#reset-cells"
[PATCH 3/4] dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
Convert the ti,sci-pm-domain to json schema for better checks and
documentation.
Differences being:
- Drop consumer example as they are documented in the corresponding
bindings themselves.
- Drop phandle description for reset consumer or cell definition as it
is redundant.
NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon
---
.../bindings/soc/ti/sci-pm-domain.txt | 65 ---
.../bindings/soc/ti/sci-pm-domain.yaml| 59 +
2 files changed, 59 insertions(+), 65 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
deleted file mode 100644
index 6217e64309de..
--- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Texas Instruments TI-SCI Generic Power Domain
--
-
-Some TI SoCs contain a system controller (like the PMMC, etc...) that is
-responsible for controlling the state of the IPs that are present.
-Communication between the host processor running an OS and the system
-controller happens through a protocol known as TI-SCI [1].
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-PM Domain Node
-==
-The PM domain node represents the global PM domain managed by the PMMC, which
-in this case is the implementation as documented by the generic PM domain
-bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because
-this relies on the TI SCI protocol to communicate with the PMMC it must be a
-child of the pmmc node.
-
-Required Properties:
-
-- compatible: should be "ti,sci-pm-domain"
-- #power-domain-cells: Can be one of the following:
- 1: Containing the device id of each node
- 2: First entry should be device id
- Second entry should be one of the floowing:
- TI_SCI_PD_EXCLUSIVE: To allow device to be
- exclusively controlled by
- the requesting hosts.
- TI_SCI_PD_SHARED: To allow device to be shared
-by multiple hosts.
-
-Example (K2G):
--
- pmmc: pmmc {
- compatible = "ti,k2g-sci";
- ...
-
- k2g_pds: power-controller {
- compatible = "ti,sci-pm-domain";
- #power-domain-cells = <1>;
- };
- };
-
-PM Domain Consumers
-===
-Hardware blocks belonging to a PM domain should contain a "power-domains"
-property that is a phandle pointing to the corresponding PM domain node
-along with an index representing the device id to be passed to the PMMC
-for device control.
-
-Required Properties:
-
-- power-domains: phandle pointing to the corresponding PM domain node
-and an ID representing the device.
-
-See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list
-of valid identifiers for k2g.
-
-Example (K2G):
-
- uart0: serial@2530c00 {
- compatible = "ns16550a";
- ...
- power-domains = <_pds 0x002c>;
- };
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
new file mode 100644
index ..9e6cb4ee9755
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI generic power domain node bindings
+
+maintainers:
+ - Nishanth Menon
+
+allOf:
+ - $ref: /schemas/power/power-domain.yaml#
+
+description: |
+ Some TI SoCs contain a system controller (like the Power Management Micro
+ Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for
controlling
+ the state of the various hardware modules present on the SoC. Communication
+ between the host processor running an OS and the system controller happens
+ through a protocol called TI System Control Interface (TI-SCI protocol).
+
+ This PM domain node represents the global PM domain managed by the TI-SCI
+ controller. Since this relies on the TI SCI protocol to communicate with
+ the TI-SCI controller, it must be a child of the TI-SCI controller node.
+
+propertie
[PATCH 4/4] dt-bindings: arm: keystone: Convert ti,sci to json schema
Convert the ti,sci to json schema for better checks and documentation.
NOTE: This change does introduce a stricter naming convention for
TI-SCI controller nodes.
NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon
---
.../bindings/arm/keystone/ti,sci.txt | 86
.../bindings/arm/keystone/ti,sci.yaml | 129 ++
2 files changed, 129 insertions(+), 86 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
deleted file mode 100644
index 6f0cd31c1520..
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Texas Instruments System Control Interface (TI-SCI) Message Protocol
-
-
-Texas Instrument's processors including those belonging to Keystone generation
-of processors have separate hardware entity which is now responsible for the
-management of the System on Chip (SoC) system. These include various system
-level functions as well.
-
-An example of such an SoC is K2G, which contains the system control hardware
-block called Power Management Micro Controller (PMMC). This hardware block is
-initialized early into boot process and provides services to Operating Systems
-on multiple processors including ones running Linux.
-
-See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
-
-TI-SCI controller Device Node:
-=
-
-The TI-SCI node describes the Texas Instrument's System Controller entity node.
-This parent node may optionally have additional children nodes which describe
-specific functionality such as clocks, power domain, reset or additional
-functionality as may be required for the SoC. This hierarchy also describes the
-relationship between the TI-SCI parent node to the child node.
-
-Required properties:
-- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
- should be "ti,am654-sci" for for TI AM654 SoC
-- mbox-names:
- "rx" - Mailbox corresponding to receive path
- "tx" - Mailbox corresponding to transmit path
-
-- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
- property should contain a phandle to the mailbox controller device
- node and an args specifier that will be the phandle to the intended
- sub-mailbox child node to be used for communication.
-
-See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
-about the generic mailbox controller and client driver bindings. Also see
-Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
-controller that is used to communicate with this System controllers.
-
-Optional Properties:
-- reg-names:
- debug_messages - Map the Debug message region
-- reg: register space corresponding to the debug_messages
-- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
-- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
- for identification of host processing entities such as virtual
- machines
-
-Example (K2G):
--
- pmmc: pmmc {
- compatible = "ti,k2g-sci";
- ti,host-id = <2>;
- mbox-names = "rx", "tx";
- mboxes= < _proxy_pmmc_rx>,
- < _proxy_pmmc_tx>;
- reg-names = "debug_messages";
- reg = <0x02921800 0x800>;
- };
-
-
-TI-SCI Client Device Node:
-=
-
-Client nodes are maintained as children of the relevant TI-SCI device node.
-
-Example (K2G):
--
- pmmc: pmmc {
- compatible = "ti,k2g-sci";
- ...
-
- my_clk_node: clk_node {
- ...
- ...
- };
-
- my_pd_node: pd_node {
- ...
- ...
- };
- };
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
new file mode 100644
index ..3e835ad84dc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI controller device node bin
[PATCH 2/4] dt-bindings: clock: Convert ti,sci-clk to json schema
Convert the ti,sci-clk to json schema for better checks and documentation.
Differences being:
- Drop consumer example as they are documented in the corresponding
bindings themselves.
- Standardize the node name as clock-controller rather than clocks as
it is more appropriate.
- Drop phandle description for clock-cells as it is redundant.
NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/clock/ti,sci-clk.txt | 36 -
.../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++
2 files changed, 52 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
deleted file mode 100644
index 4e59dc6b1778..
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Texas Instruments TI-SCI Clocks
-===
-
-All clocks on Texas Instruments' SoCs that contain a System Controller,
-are only controlled by this entity. Communication between a host processor
-running an OS and the System Controller happens through a protocol known
-as TI-SCI[1]. This clock implementation plugs into the common clock
-framework and makes use of the TI-SCI protocol on clock API requests.
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-Required properties:
-- compatible: Must be "ti,k2g-sci-clk"
-- #clock-cells: Shall be 2.
- In clock consumers, this cell represents the device ID and clock ID
- exposed by the PM firmware. The list of valid values for the device IDs
- and clocks IDs for 66AK2G SoC are documented at
- http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Examples:
-
-
-pmmc: pmmc {
- compatible = "ti,k2g-sci";
-
- k2g_clks: clocks {
- compatible = "ti,k2g-sci-clk";
- #clock-cells = <2>;
- };
-};
-
-uart0: serial@2530c00 {
- compatible = "ns16550a";
- clocks = <_clks 0x2c 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
new file mode 100644
index ..72633651f0c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI clock controller node bindings
+
+maintainers:
+ - Nishanth Menon
+
+allOf:
+ - $ref: /schemas/clock/clock.yaml#
+
+description: |
+ Some TI SoCs contain a system controller (like the Power Management Micro
+ Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for
controlling
+ the state of the various hardware modules present on the SoC. Communication
+ between the host processor running an OS and the system controller happens
+ through a protocol called TI System Control Interface (TI-SCI protocol).
+
+ This clock controller node uses the TI SCI protocol to perform various clock
+ management of various hardware modules (devices) present on the SoC. This
+ node must be a child node of the associated TI-SCI system controller node.
+
+properties:
+ $nodename:
+pattern: "^clock-controller$"
+
+ compatible:
+const: ti,k2g-sci-clk
+
+ "#clock-cells":
+const: 2
+description:
+ The two cells represent values that the TI-SCI controller defines.
+
+ The first cell should contain the device ID.
+
+ The second cell should contain the clock ID.
+
+ Please see http://processors.wiki.ti.com/index.php/TISCI for
+ protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+ - |
+k3_clks: clock-controller {
+compatible = "ti,k2g-sci-clk";
+#clock-cells = <2>;
+};
--
2.31.0
[PATCH 0/4] dt-bindings: soc/arm: Convert pending ti,sci* bindings to json format
Hi, I understand that the following series belong to various maintainers, but, it is a bit better reviewed as a single series for cohesiveness. There are also dts fixups that this series exposes, which is good, but I chose to hold them back for now pending binding review at least. The complete series is available in [1] if folks are curious. Nishanth Menon (4): dt-bindings: reset: Convert ti,sci-reset to json schema dt-bindings: clock: Convert ti,sci-clk to json schema dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema dt-bindings: arm: keystone: Convert ti,sci to json schema .../bindings/arm/keystone/ti,sci.txt | 86 .../bindings/arm/keystone/ti,sci.yaml | 129 ++ .../devicetree/bindings/clock/ti,sci-clk.txt | 36 - .../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++ .../bindings/reset/ti,sci-reset.txt | 62 - .../bindings/reset/ti,sci-reset.yaml | 51 +++ .../bindings/soc/ti/sci-pm-domain.txt | 65 - .../bindings/soc/ti/sci-pm-domain.yaml| 59 8 files changed, 291 insertions(+), 249 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci Regards, Nishanth Menon -- 2.31.0
Re: [PATCH V2] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
On 16:17-20210415, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> > b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
> > new file mode 100644
> > index ..08a4837fdfcc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
[...]
> > +
> > + interrupt-names:
> > +minItems: 1
> > +maxItems: 100
> > +items:
> > + - pattern: "^rx_[0-9]{3}$"
>
> Need to drop the '-' to make this apply to all entries. Otherwise, it's
> just the first one.
Aaah.. Thanks. done in v3[1]
[1] https://lore.kernel.org/r/20210416005953.17147-1...@ti.com
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH V3] dt-bindings: mailbox: ti,secure-proxy: Convert to json schema
Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- Dropped the example usage of mailbox client, it is better done in
tisci node definition.
- Switched reg usage for address-cells and size-cells 1 - aligned with
schema checks as well.
- included header in example for a buildable example.
While at this, lets make sure to support upto 100 rx threads even though
typically upto 1 threads is practically in use.
NOTE: The following checkpatch warning is generated since we do include the
header
in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
Changes since v2:
- Subject line rewording to indicate json schema rather than yaml
- Review comment: Dropped "-" in interrupt-names pattern so that it will match
all
entries
- Minor commit message formatting changes
V2: https://lore.kernel.org/linux-arm-kernel/20210413224535.30910-1...@ti.com/
V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1...@ti.com/
.../bindings/mailbox/ti,secure-proxy.txt | 50
.../bindings/mailbox/ti,secure-proxy.yaml | 79 +++
2 files changed, 79 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be "ti,am654-secure-proxy"
-- reg-namestarget_data - Map the proxy data region
- rt - Map the realtime status region
- scfg - Map the configuration region
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 1 and shall refer to the transfer path
- called thread.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(AM654):
-
-
- secure_proxy: mailbox@32c0 {
- compatible = "ti,am654-secure-proxy";
- #mbox-cells = <1>;
- reg-names = "target_data", "rt", "scfg";
- reg = <0x0 0x32c0 0x0 0x10>,
- <0x0 0x3240 0x0 0x10>,
- <0x0 0x3280 0x0 0x10>;
- interrupt-names = "rx_011";
- interrupts = ;
- };
-
- dmsc: dmsc {
- [...]
- mbox-names = "rx", "tx";
- # RX Thread ID is 11
- # TX Thread ID is 13
- mboxes= <_proxy 11>,
- <_proxy 13>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index ..eea822861804
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' secure proxy is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
+ Message manager is broken up into different address regions that are
+ called "threads" or "proxies" - each instance is unidirectional and is
+ instantiated at SoC integration level by system controller to indicate
+
[PATCH V2] dt-bindings: mailbox: ti,message-manager: Convert to json schema
Convert the ti,message-manager to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
tisci node definition
- included header in example for buildable example
NOTE: The following checkpatch warning is generated since we do include
the header in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
Changes since v1:
- Fixed title in yaml (not driver)
- Commit message update to fix up a copy paste error (not secure-proxy).
- Subject line rewording to indicate json schema rather than yaml -
more inline with patches elsewhere.
V1: https://lore.kernel.org/linux-arm-kernel/20210414002721.23638-1...@ti.com/
.../bindings/mailbox/ti,message-manager.txt | 50 -
.../bindings/mailbox/ti,message-manager.yaml | 75 +++
2 files changed, 75 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
deleted file mode 100644
index ebf0e3710cee..
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Message Manager Driver
-
-
-The Texas Instruments' Message Manager is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The Message
-manager is broken up into queues in different address regions that are called
-"proxies" - each instance is unidirectional and is instantiated at SoC
-integration level to indicate receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be: "ti,k2g-message-manager"
-- reg-namesqueue_proxy_region - Map the queue proxy region.
- queue_state_debug_region - Map the queue state debug
- region.
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 2. Contains the queue ID and proxy ID in that
- order referring to the transfer path.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
- For ti,k2g-message-manager, this shall contain:
- "rx_005", "rx_057"
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(K2G):
-
-
- msgmgr: msgmgr@2a0 {
- compatible = "ti,k2g-message-manager";
- #mbox-cells = <2>;
- reg-names = "queue_proxy_region", "queue_state_debug_region";
- reg = <0x02a0 0x40>, <0x028c3400 0x400>;
- interrupt-names = "rx_005", "rx_057";
- interrupts = ,
-;
- };
-
- pmmc: pmmc {
- [...]
- mbox-names = "rx", "tx";
- # RX queue ID is 5, proxy ID is 2
- # TX queue ID is 0, proxy ID is 0
- mboxes= < 5 2>,
- < 0 0>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
new file mode 100644
index ..1cbf9a75522e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' message manager node bindings
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' Message Manager is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
Message
+ manager is broken up into queues in different address regions that are called
+ "proxies" - each instance is unidirectional and is instantiated at SoC
+ integration level to indicate receive or transmit path.
+
+properties:
+ $nodename:
+pattern: "^mailbox@[0-9a-f]+$"
+
+ compatible:
+const: ti,k2g-message-manager
+
+
Re: [PATCH] dt-bindings: mailbox: ti,message-manager: Convert to yaml
On 19:32-20210415, Lokesh Vutla wrote: > [..snip..] > > > diff --git > > a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > new file mode 100644 > > index ..4987e803ac37 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml > > @@ -0,0 +1,75 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Texas Instruments' Message Manager Driver > > Driver is not the right word here. Can you change it to node? Indeed, thanks. v2 incoming. I also noticed a commit message typo while at it. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] dt-bindings: mailbox: ti,message-manager: Convert to yaml
Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
tisci node definition
- included header in example for buildable example
NOTE: The following checkpatch warning is generated since we do include
the header
in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
Depending on how [1] turns out in discussion, we might want to queue [2]
appropriately.
[1]
https://lore.kernel.org/linux-arm-kernel/cak8p3a1l8rwpr5b66v6su8-m7-sca0wzqr_g_4knv4dnrky...@mail.gmail.com/
[2] https://lore.kernel.org/linux-arm-kernel/20210414001926.20002-1...@ti.com/
.../bindings/mailbox/ti,message-manager.txt | 50 -
.../bindings/mailbox/ti,message-manager.yaml | 75 +++
2 files changed, 75 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
deleted file mode 100644
index ebf0e3710cee..
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Message Manager Driver
-
-
-The Texas Instruments' Message Manager is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The Message
-manager is broken up into queues in different address regions that are called
-"proxies" - each instance is unidirectional and is instantiated at SoC
-integration level to indicate receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be: "ti,k2g-message-manager"
-- reg-namesqueue_proxy_region - Map the queue proxy region.
- queue_state_debug_region - Map the queue state debug
- region.
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 2. Contains the queue ID and proxy ID in that
- order referring to the transfer path.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
- For ti,k2g-message-manager, this shall contain:
- "rx_005", "rx_057"
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(K2G):
-
-
- msgmgr: msgmgr@2a0 {
- compatible = "ti,k2g-message-manager";
- #mbox-cells = <2>;
- reg-names = "queue_proxy_region", "queue_state_debug_region";
- reg = <0x02a0 0x40>, <0x028c3400 0x400>;
- interrupt-names = "rx_005", "rx_057";
- interrupts = ,
-;
- };
-
- pmmc: pmmc {
- [...]
- mbox-names = "rx", "tx";
- # RX queue ID is 5, proxy ID is 2
- # TX queue ID is 0, proxy ID is 0
- mboxes= < 5 2>,
- < 0 0>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
new file mode 100644
index ..4987e803ac37
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,message-manager.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Message Manager Driver
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' Message Manager is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
Message
+ manager is broken up into queues in different address regions that are called
+ "proxies" - each instance is unidirectional and is instantiated at SoC
+ integration level to indicate receive or transmit path.
+
+properties:
+ $nodename:
+pattern: "^mailbox@[0-9a-f]+$"
+
+ compatible:
+const: ti,k2g-message-manager
+
+ "#mbox-cells":
+cons
[PATCH] ARM: dts: keystone-k2g: Rename message-manager node
Rename message-manager instance node name to be better aligned with
current style of device tree nodes for mailboxes.
Signed-off-by: Nishanth Menon
---
Santosh:
- This is'nt critical to queue up for 5.13-rc1 window, but just getting
it out of the way. I noticed it as I was converting the binding to
yaml. (patch for yaml conversion for the node follows)
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi
b/arch/arm/boot/dts/keystone-k2g.dtsi
index 05a75019275e..e5c813b5556d 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -242,7 +242,7 @@ dsp0: dsp@1080 {
status = "disabled";
};
- msgmgr: msgmgr@2a0 {
+ msgmgr: mailbox@2a0 {
compatible = "ti,k2g-message-manager";
#mbox-cells = <2>;
reg-names = "queue_proxy_region",
--
2.31.0
[PATCH V2] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
tisci node definition
- Switched reg usage for address-cells and size-cells 1 - aligned with
schema checks as well
- included header in example for buildable example
While at this, lets make sure to support upto 100 rx threads even though
typically upto 1 threads is practically in use.
NOTE: The following checkpatch warning is generated since we do include the
header
in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
Changes since V1: (Thanks Suman for some offline comments)
- Strengthened interrupt-names property to be on rails
- More documentation (we dont want an information loss between txt and
yaml)
- Added a max interrupts of 100, which is a rather conservative limit on
current devices, but who knows..
- Commit message updates
- compatible is a simpler const.
- interrupt-names are required property - makes no sense in not knowing
which interrupts belong to which thread irqs.
V1: https://lore.kernel.org/linux-arm-kernel/20210413171230.5872-1...@ti.com/
.../bindings/mailbox/ti,secure-proxy.txt | 50
.../bindings/mailbox/ti,secure-proxy.yaml | 79 +++
2 files changed, 79 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be "ti,am654-secure-proxy"
-- reg-namestarget_data - Map the proxy data region
- rt - Map the realtime status region
- scfg - Map the configuration region
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 1 and shall refer to the transfer path
- called thread.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(AM654):
-
-
- secure_proxy: mailbox@32c0 {
- compatible = "ti,am654-secure-proxy";
- #mbox-cells = <1>;
- reg-names = "target_data", "rt", "scfg";
- reg = <0x0 0x32c0 0x0 0x10>,
- <0x0 0x3240 0x0 0x10>,
- <0x0 0x3280 0x0 0x10>;
- interrupt-names = "rx_011";
- interrupts = ;
- };
-
- dmsc: dmsc {
- [...]
- mbox-names = "rx", "tx";
- # RX Thread ID is 11
- # TX Thread ID is 13
- mboxes= <_proxy 11>,
- <_proxy 13>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index ..08a4837fdfcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' secure proxy is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
+ Message manager is broken up into different address regions that are
+
Re: [PATCH] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
On 12:12-20210413, Nishanth Menon wrote: [...] > +properties: > + $nodename: > +pattern: "^mailbox@[0-9a-f]+$" > + > + compatible: > +const: ti,am654-secure-proxy > + > + "#mbox-cells": > +const: 1 > + > + reg-names: > +items: > + - const: target_data > + - const: rt > + - const: scfg > + > + reg: > +minItems: 3 > + > + interrupt-names: > +minItems: 1 > +description: > + Contains the interrupt name information for the Rx interrupt path for > + secure proxy. > + > + interrupts: > +minItems: 1 > +description: > + Contains the interrupt information for the Rx interrupt path for secure I think I can strengthen it quite a bit here. let me post a v2 further that has lesser information loss in the conversion and checks are stronger. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] dt-bindings: mailbox: ti,secure-proxy: Convert to yaml
Convert the ti,secure-proxy to yaml for better checks and documentation.
Differences being mostly in the examples:
- I've dropped the example usage of mailbox client, it is better done in
tisci node definition
- Switched reg usage for address-cells and size-cells 1 - aligned with
schema checks as well
- included header in example for buildable example
NOTE: The following warning is generated since we do include the header
in the example, but this is a false positive warning.
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
Signed-off-by: Nishanth Menon
---
.../bindings/mailbox/ti,secure-proxy.txt | 50 -
.../bindings/mailbox/ti,secure-proxy.yaml | 72 +++
2 files changed, 72 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
create mode 100644
Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
deleted file mode 100644
index 6c9c7daf0f5c..
--- a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Texas Instruments' Secure Proxy
-
-
-The Texas Instruments' secure proxy is a mailbox controller that has
-configurable queues selectable at SoC(System on Chip) integration. The
-Message manager is broken up into different address regions that are
-called "threads" or "proxies" - each instance is unidirectional and is
-instantiated at SoC integration level by system controller to indicate
-receive or transmit path.
-
-Message Manager Device Node:
-===
-Required properties:
-
-- compatible: Shall be "ti,am654-secure-proxy"
-- reg-namestarget_data - Map the proxy data region
- rt - Map the realtime status region
- scfg - Map the configuration region
-- reg: Contains the register map per reg-names.
-- #mbox-cells Shall be 1 and shall refer to the transfer path
- called thread.
-- interrupt-names: Contains interrupt names matching the rx transfer path
- for a given SoC. Receive interrupts shall be of the
- format: "rx_".
-- interrupts: Contains the interrupt information corresponding to
- interrupt-names property.
-
-Example(AM654):
-
-
- secure_proxy: mailbox@32c0 {
- compatible = "ti,am654-secure-proxy";
- #mbox-cells = <1>;
- reg-names = "target_data", "rt", "scfg";
- reg = <0x0 0x32c0 0x0 0x10>,
- <0x0 0x3240 0x0 0x10>,
- <0x0 0x3280 0x0 0x10>;
- interrupt-names = "rx_011";
- interrupts = ;
- };
-
- dmsc: dmsc {
- [...]
- mbox-names = "rx", "tx";
- # RX Thread ID is 11
- # TX Thread ID is 13
- mboxes= <_proxy 11>,
- <_proxy 13>;
- [...]
- };
diff --git a/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
new file mode 100644
index ..88eb32cb5678
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,secure-proxy.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/ti,secure-proxy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments' Secure Proxy
+
+maintainers:
+ - Nishanth Menon
+
+description: |
+ The Texas Instruments' secure proxy is a mailbox controller that has
+ configurable queues selectable at SoC(System on Chip) integration. The
+ Message manager is broken up into different address regions that are
+ called "threads" or "proxies" - each instance is unidirectional and is
+ instantiated at SoC integration level by system controller to indicate
+ receive or transmit path.
+
+properties:
+ $nodename:
+pattern: "^mailbox@[0-9a-f]+$"
+
+ compatible:
+const: ti,am654-secure-proxy
+
+ "#mbox-cells":
+const: 1
+
+ reg-names:
+items:
+ - const: target_data
+ - const: rt
+ - const: scfg
+
+ reg:
+minItems: 3
+
+ interrupt-names:
+minItems: 1
+description:
+ Contains the interrupt name information for the Rx interrupt path for
+ secure proxy.
+
+ interrupts:
+minItems: 1
+descri
Re: [GIT PULL] arm64: dts: TI K3 updates for v5.13
On 22:13-20210408, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:34 PM Nishanth Menon wrote:
> > On 17:24-20210408, Arnd Bergmann wrote:
> > >
> > > ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg):
> > > /bus@f4000/interrupt-controller0: missing or empty reg/ranges property
> > > ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg):
> > > /bus@f4000/dmss: missing or empty reg/ranges property
> > > ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg):
> > > /bus@f4000/bus@400/interrupt-controller1: missing or empty reg/ranges
> > > property
> > >
> > > ti/k3-am642-evm.dt.yaml: bus@400: interrupt-controller1: {'type':
> > > 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> > > 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
> > > 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
> > > 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle':
> > > [[5]]}
> > > ti/k3-am642-evm.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not
> > > allowed for {'compatible': ['simple-mfd'], '#address-cells': [[2]],
> > > '#size-cells': [[2]], 'dma-ranges': True, 'ranges': 'phandle': [[7]]}}
> > > ti/k3-am642-evm.dt.yaml: bus@f4000: interrupt-controller0: {'type':
> > > 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> > > 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
> > > 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
> > > 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle':
> > > [[15]]}
> > > ti/k3-am642-evm.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns',
> > > 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the
> > > regexes: '^partition@', 'pinctrl-[0-9]+'
> > > ti/k3-am642-sk.dt.yaml: bus@400: interrupt-controller1: {'type':
> > > 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> > > 'ti,intr-trigger-type': [[1]], ...
> > > ti/k3-am642-sk.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not
> > > allowed for {'compatible': ['simple-mfd'], ...
> > > ti/k3-am642-sk.dt.yaml: bus@f4000: interrupt-controller0: {'type':
> > > 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> > > 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
> > > 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
> > > 'ti,sci-dev-id': [[3]], 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle':
> > > [[11]]}
> > > ti/k3-am642-sk.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns',
> > > 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the
> > > regexes: '^partition@', 'pinctrl-[0-9]+'
> > > ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay',
> > > 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not
> > > match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> > >
> > >
> > > merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296
> >
> >
> > We have a bunch of problems with interrupt controller definitions -
> > attempts in [1] [2] did'nt seem to come to any form of conclusion yet.
> >
> > Cdns is a convert from txt to yaml and is queued on Marks' tree[3]
>
> Ok, thanks for taking a look
>
Apologies on not flagging in my PR itself.
> > These issues pre-existed in existing definitions and/or convertion
> > from txt and we are already working to make sure we try and reach a
> > conclusion soon[4]. I am guessing from your note that it is high time we
> > put our foot down on txt bindings and clean yamls, I will ensure we
> > follow up on that.
>
> I'm still trying to figure out how to best script it, my intention was to
> only list issues that got introduced in the latest patches rather than
> the existing problems.
I had done a bit of scripting around this already in my checker:
https://github.com/nmenon/kernel_patch_verify/blob/master/kernel_patch_verify#L212
Though it never works quite right all the time.. So, i do run explicit
checks afterwards to try and catch these.. and containerizing them
helped deployment aspects(developers having different schema package
versions) in control as well.
but yeah, a clean way of doing things still eludes me.
>
> On the other hand, it would indeed help to address any issues that
> are going to come up in every newly added board first, and then
> eventually get to all the remaining warnings for issues with the
> yaml bindings.
yep, some of the
Re: [GIT PULL] arm64: dts: TI K3 updates for v5.13
On 17:24-20210408, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On Mon, 5 Apr 2021 10:53:36 -0500, Nishanth Menon wrote:
> > Please pull the following device tree changes for v5.13 cycle.
> >
> > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> >
> > Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> >
> > are available in the Git repository at:
> >
> > [...]
>
> Merged into arm/dt, thanks!
Thanks.
>
> There are a couple added warnings from 'make W=1 dtbs_check' though:
>
> ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg):
> /bus@f4000/interrupt-controller0: missing or empty reg/ranges property
> ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus@f4000/dmss:
> missing or empty reg/ranges property
> ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg):
> /bus@f4000/bus@400/interrupt-controller1: missing or empty reg/ranges
> property
>
> ti/k3-am642-evm.dt.yaml: bus@400: interrupt-controller1: {'type':
> 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True,
> 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]],
> 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle':
> [[5]]}
> ti/k3-am642-evm.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed
> for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells':
> [[2]], 'dma-ranges': True, 'ranges': 'phandle': [[7]]}}
> ti/k3-am642-evm.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'}
> is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type':
> [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]],
> '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]],
> 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
> ti/k3-am642-evm.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns',
> 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the
> regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-am642-sk.dt.yaml: bus@400: interrupt-controller1: {'type':
> 'object'} is not allowed for {'compatible': ['ti,sci-intr'],
> 'ti,intr-trigger-type': [[1]], ...
> ti/k3-am642-sk.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed
> for {'compatible': ['simple-mfd'], ...
> ti/k3-am642-sk.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'}
> is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type':
> [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]],
> '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]],
> 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
> ti/k3-am642-sk.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns',
> 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the
> regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay',
> 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not
> match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
>
>
> merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296
We have a bunch of problems with interrupt controller definitions -
attempts in [1] [2] did'nt seem to come to any form of conclusion yet.
Cdns is a convert from txt to yaml and is queued on Marks' tree[3]
These issues pre-existed in existing definitions and/or convertion
from txt and we are already working to make sure we try and reach a
conclusion soon[4]. I am guessing from your note that it is high time we
put our foot down on txt bindings and clean yamls, I will ensure we
follow up on that.
[1]
https://lore.kernel.org/linux-devicetree/cal_jsq++dyikg9smqgx9fapdjnvrezcxnb0y5uh-5_2gbzt...@mail.gmail.com/#t
[2]
https://lore.kernel.org/linux-arm-kernel/20210311215914.pgpz2yymmfqlainl@episode/
[3]
https://lore.kernel.org/linux-arm-kernel/161726952255.2486.16196604421904035265.b4...@kernel.org/
[4]
https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem
On 17:13-20210407, Jan Kiszka wrote: > On 07.04.21 16:59, Nishanth Menon wrote: > > On 16:13-20210407, Aswath Govindraju wrote: > >> UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1]. > >> > >> Add support by removing the no-1-8-v tag and including the voltage > >> regulator device tree nodes for power cycling. > >> > >> [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1 > >> > >> Signed-off-by: Aswath Govindraju > > > >> --- > >> > >> test logs: > >> https://pastebin.ubuntu.com/p/vpYbY9QWh8/ > >> > > Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already > > out). but it does trigger an interesting discussion.. > > > >> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 - > >> .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++ > >> 2 files changed, 33 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > >> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > >> index cb340d1b401f..632f32fce4a1 100644 > >> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > >> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > >> @@ -301,7 +301,6 @@ > >>ti,otap-del-sel = <0x2>; > >>ti,trm-icp = <0x8>; > >>dma-coherent; > >> - no-1-8-v; > >>}; > >> > > > > Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0, > > 2.0, 2.1 coming along, the plan for TI was to support older revs via > > overlays hoping that older boards will eventually get replaced or die > > out of lack of use.. but you do have production on 1.0 -> so would you > > rather handle this in overlay OR IOT boards dts introduce no-1-8-v > > property? > > I'm fine with pulling anything needed into our board-specific DTs. Those > pending are for SR1.0 boards only. SR2 will come later and have their > own DTs. OK - I think the safe option will be for Ashwath to add no-1-8-v into IOT board.dts as part of this patch to maintain bisectability. > Didn't follow the thread: Where is this patch located wrt my IOT2050 > series? Does it come first first, and we would have to rebase? Or would > this change rather have to move the flag to k3-am65-iot2050-common.dtsi? 5.13 PR is sent https://lore.kernel.org/linux-arm-kernel/20210405155336.smohb7uzkperqwuz@reflex/ IoT is part of that.. I am guessing Arnd / Olof will pick it up later this week or weekend once it goes through their checklist. we are starting to see 5.14 material now, so nothing you need to do from rebase perspective - testing will be appreciated to make sure that the new patches have'nt broken your board. > Thanks a lot for having an eye on these subtle dependencies! Sure.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am65: Add support for UHS-I modes in MMCSD1 subsystem
On 16:13-20210407, Aswath Govindraju wrote: > UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1]. > > Add support by removing the no-1-8-v tag and including the voltage > regulator device tree nodes for power cycling. > > [1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1 > > Signed-off-by: Aswath Govindraju > --- > > test logs: > https://pastebin.ubuntu.com/p/vpYbY9QWh8/ > Thanks, but I dont plan on queuing this for 5.13-rc1 (my PR is already out). but it does trigger an interesting discussion.. > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 1 - > .../arm64/boot/dts/ti/k3-am654-base-board.dts | 33 +++ > 2 files changed, 33 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > index cb340d1b401f..632f32fce4a1 100644 > --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi > @@ -301,7 +301,6 @@ > ti,otap-del-sel = <0x2>; > ti,trm-icp = <0x8>; > dma-coherent; > - no-1-8-v; > }; > Jan - this will break your IOT SR1.0 boards, no? with all the SR1.0, 2.0, 2.1 coming along, the plan for TI was to support older revs via overlays hoping that older boards will eventually get replaced or die out of lack of use.. but you do have production on 1.0 -> so would you rather handle this in overlay OR IOT boards dts introduce no-1-8-v property? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[GIT PULL] arm64: dts: TI K3 updates for v5.13
/k3-j721e-mcu-wakeup.dtsi| 4 +- arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi| 4 +- include/dt-bindings/pinctrl/k3.h | 5 +- 23 files changed, 3501 insertions(+), 11 deletions(-) create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am642-evm.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am642-sk.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D signature.asc Description: PGP signature
Re: (subset) [PATCH 0/4] Convert Cadence QSPI bindings to yaml
On Fri, 26 Mar 2021 18:30:30 +0530, Pratyush Yadav wrote: > This series picks up Ramuthevar's effort on converting the Cadence QSPI > bindings to yaml [0]. During the conversion process, I discovered that > some TI device tree files were not using the compatible correctly. Those > are fixed in patches 1-3. > > [0] > https://patchwork.kernel.org/project/spi-devel-general/patch/20201116031003.19062-6-vadivel.muruganx.ramuthe...@linux.intel.com/ > > [...] Hi Pratyush Yadav, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible commit: f1b6f6e7f595ed66ba5f5d628df3d259218d584b [2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible commit: 0e941f496a8bdc47d34199c17f81b09b0dbe14ae [3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible commit: 112e5934ff3a7505e583365213a27f990922b76b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v9 0/3] J7200: Add support for GPIO and higher speed modes in MMCSD subsystems
On Fri, 26 Mar 2021 12:11:17 +0530, Aswath Govindraju wrote: > The following series of patches > - Add support for GPIO subsystem in main and wakeup domains. > - Add voltage regulator device tree nodes and their corresponding pinmux > to support power cycle and voltage switch required for UHS-I modes > - sets respective tags in sdhci0 node to support higher speeds > - remove no-1-8-v tag from sdhci1 node to support UHS-I modes > - Update delay values for various speed modes supported. > > [...] Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/3] arm64: dts: ti: k3-j7200: Add gpio nodes commit: e0b2e6af39ea94a6fdba53571e6711df49b6ee8d [2/3] arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules commit: f4cc7daf460b285d3b318496654dab01472df8e4 [3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems commit: 9437499086c24abf298bc3c3a053faedfc19bab1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v13 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
On 21:56-20210323, Roger Lu wrote: > Document the binding for enabling mtk svs on MediaTek SoC. > > Signed-off-by: Roger Lu > --- > .../bindings/soc/mediatek/mtk-svs.yaml| 81 +++ > 1 file changed, 81 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml > > diff --git a/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml > b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml > new file mode 100644 > index ..0d8d12f927de > --- /dev/null > +++ b/Documentation/devicetree/bindings/soc/mediatek/mtk-svs.yaml > @@ -0,0 +1,81 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/mediatek/mtk-svs.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek Smart Voltage Scaling (SVS) Device Tree Bindings > + > +maintainers: > + - Roger Lu > + - Matthias Brugger > + - Kevin Hilman > + - Nishanth Menon Please drop me off the list. I would'nt know what to do with SVS :) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/2] AM64: Add support for GPIO
On Fri, 19 Mar 2021 10:49:48 +0530, Aswath Govindraju wrote: > The following series of patches adds support for gpio on AM642 evm/sk. > > GPIO test logs, > AM642-evm: https://pastebin.ubuntu.com/p/PCGmY34spb/ > AM642-sk: https://pastebin.ubuntu.com/p/nrxzyQTKkX/ > > Changes since v2: > - Rebased the series on top of ti-k3-dts-next branch > - Added gpio test logs. > > [...] Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/2] arm64: dts: ti: k3-am64: Add GPIO DT nodes commit: 01a91e01b8fddaeb37b953a5e39eafbdf2d4b061 [2/2] arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware usage commit: d5a4d5413dd833b3ceba395ba77f00470a3ffbe8 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v7 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
On 18:42-20210322, Aswath Govindraju wrote:
> The following speed modes are now supported in J7200 SoC,
> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
> - UHS-I speed modes in MMCSD1 subsystem [1].
>
> Add support for UHS-I modes by adding voltage regulator device tree nodes
> and corresponding pinmux details, to power cycle and voltage switch cards.
> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
> device tree nodes.
>
> Also update the delay values for various speed modes supported, based on
> the revised january 2021 J7200 datasheet[2].
>
> [1] - section 12.3.6.1.1 MMCSD Features, in
> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
> (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>
> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
> (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
>
> Signed-off-by: Aswath Govindraju
> ---
> .../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
> 2 files changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index b493f939b09a..de8c06bdc825 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -16,6 +16,29 @@
> stdout-path = "serial2:115200n8";
> bootargs = "console=ttyS2,115200n8
> earlycon=ns16550a,mmio32,0x0280";
> };
> +
> + vdd_mmc1: fixedregulator-sd {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd_mmc1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
> + enable-active-high;
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
is that gpio ?
I'd encourage to use vin-supply as well.
> + };
> +
> + vdd_sd_dv: gpio-regulator-vdd-sd-dv {
What does this drive? TLV71033 ?
> + compatible = "regulator-gpio";
> + regulator-name = "vdd_sd_dv";
> + pinctrl-names = "default";
> + pinctrl-0 = <_sd_dv_pins_default>;
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
normally, I'd encourage to use vin-supply as well.
> + gpios = <_gpio0 55 GPIO_ACTIVE_HIGH>;
> + states = <180 0x0
> + 330 0x1>;
states = <180 0x0>,
<330 0x1>;
Can you look at j721e as reference?
> + };
> };
>
Kishon,
can you look closer at this series?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v6 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
On 09:14-20210319, Aswath Govindraju wrote:
> The following speed modes are now supported in J7200 SoC,
> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
> - UHS-I speed modes in MMCSD1 subsystem [1].
>
> Add support for UHS-I modes by adding voltage regulator device tree nodes
> and corresponding pinmux details, to power cycle and voltage switch cards.
> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
> device tree nodes.
>
> Also update the delay values for various speed modes supported, based on
> the revised january 2021 J7200 datasheet[2].
>
> [1] - section 12.3.6.1.1 MMCSD Features, in
> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
> (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>
> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
> (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
>
> Signed-off-by: Aswath Govindraju
> ---
[...]
> +
> + vdd_sd_dv_pins_default: vdd_sd_dv_pins_default {
Nope. Use:
vdd_sd_dv_pins_default: vdd-sd-dv-pins-default
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [RESEND PATCH v2 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
On Thu, 18 Mar 2021 17:07:56 +0530, Vignesh Raghavendra wrote: > AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem > (FSS). Add DT entry for the same. Hi Vignesh Raghavendra, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/2] arm64: dts: ti: k3-am64-main: Add OSPI node commit: 81623c55868475c4a81c7cdce38191c92ea37022 [2/2] arm64: dts: ti: k3-am64-evm/sk: Add OSPI flash DT node commit: e4e4e89482eafab0774ac0f93dc998eea84e626c Thanks for rebasing and helping sequence. I have taken note that we will be converting the binding to yaml in near future, so inline with what we are doing now, accepting the patches. All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [RESEND PATCH] arm64: dts: ti: k3-am64-main: Add ADC nodes
On Thu, 18 Mar 2021 17:04:43 +0530, Vignesh Raghavendra wrote: > AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same. > > Default usecase is to control ADC from non Linux core on the system on > AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts > file. ADC lines are not pinned out on AM642 SK board, therefore disable > the node in k3-am642-sk.dts file. Hi Vignesh Raghavendra, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-am64-main: Add ADC nodes commit: fad4e18fe4dccacf68418da01e98c4b8fb590023 Thanks for rebasing and helping sequence. I have taken note that we will be converting the binding to yaml in near future, so inline with what we are doing now, accepting the patch. All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/2] AM64: Add USB support
On 20:22-20210317, Kishon Vijay Abraham I wrote: > Aswath and Nishanth, > > On 17/03/21 10:00 am, Aswath Govindraju wrote: > > The following series of patches, add USB support for AM642 evm. > > > > USB test logs, > > https://pastebin.ubuntu.com/p/YSQRBWGmzd/ > > Vinod has provided stable tag [1] > git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git > tags/ti-serdes-for-5.13 > > This should unblock us from up-streaming SK along with this. > Awesome. Thanks Vinod and Kishon for helping co-ordinate this. Ashwath, Please highlight this detail as part SK USB3 addendum series and I can pick it up as part of pulling that series in. our window is starting to narrow, so lets respin asap. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/3] AM64: Add SERDES DT bindings
On 12:05-20210317, Vinod Koul wrote: > On 10-03-21, 16:57, Kishon Vijay Abraham I wrote: > > Patch series adds device tree bindings to support SERDES in AM64 > > platform. > > > > This is split from [1] since this binding is also required for AM64 > > USB DT patches to be merged. > > > > Vinod, > > > > Once the 1st patch of the series is reviewed by Rob, can you merge and > > prepare a immutable tag to be used by Nishant Menon so that he can merge > > USB3 DT patches. > > Applied and tag: > > git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git > tags/ti-serdes-for-5.13 > Thanks Vinod. Much appreciated. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/2] AM64: Add USB support
On Wed, 17 Mar 2021 10:00:04 +0530, Aswath Govindraju wrote: > The following series of patches, add USB support for AM642 evm. > > USB test logs, > https://pastebin.ubuntu.com/p/YSQRBWGmzd/ > > Changes since v2: > - dropped compatible string "ti,j721e-usb" leading to DT schema errors > - Reran test logs > - Couldn't pick up reviewed-by from kishon as a change was made in the > patch > > [...] Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/2] arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem commit: d06a661309d30b654b74a4633dd78804ef16369f [2/2] arm64: dts: ti: k3-am642-evm: Add USB support commit: 04a80a75baa1c80f7e5096147b6173c13ca3d3e0 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 0/2] AM64: Add USB support
On 16:57-20210310, Aswath Govindraju wrote: > The following series of patches, add USB support for AM642 evm. > > USB test logs, > https://pastebin.ubuntu.com/p/Qrbb7SGv8N/ > > Changes since v1: > - Rebased the patches on top of ti-k3-dts-next > - Added test logs > > Aswath Govindraju (2): > arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem > arm64: dts: ti: k3-am642-evm: Add USB support > > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 18 ++ > 2 files changed, 48 insertions(+) > > -- > 2.17.1 > I see: /workdir/arch/arm64/boot/dts/ti/k3-am642-evm.dt.yaml: cdns-usb@f90: compatible: 'oneOf' conditional failed, one must be fixed: I assume there is a reason for this? Can you capture that in the commit message? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [RESEND PATCH 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
On 17:31-20210315, Vignesh Raghavendra wrote: > AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem > (FSS). Add DT entry for the same. > > Signed-off-by: Vignesh Raghavendra > Reviewed-by: Pratyush Yadav > --- > Resend: > Rebase onto latest -next > > v1: lore.kernel.org/r/20210309130514.11740-1-vigne...@ti.com Thanks, but we will need to rebase -> so lets sequence this right offline. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am64-main: Add ADC nodes
On 17:05-20210311, Lokesh Vutla wrote: > > > On 09/03/21 6:37 pm, Vignesh Raghavendra wrote: > > AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same. > > > > Default usecase is to control ADC from non Linux core on the system on > > AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts > > file. ADC lines are not pinned out on AM642 SK board, therefore disable > > the node in k3-am642-sk.dts file. > > > > Signed-off-by: Vignesh Raghavendra > > Reviewed-by: Lokesh Vutla Looks like the patch wont apply anymore after all the cpsw nodes got in. could you rebase and repost? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] soc: ti: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
On 11:33-20210313, Wang Qing wrote: > Fix the following coccicheck warning: > WARNING:pm_sr_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE. > Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
Andre, Rob, On 16:38-20210126, Andre Przywara wrote: > > Now that I look back at the dtc change, I'm now confused why this > > check got applied. Both David and I wanted changes in regards to > > #address-cells. Either a separate check or part of interrupt-map checks. > > And the interrupt-map check never got applied. Andre? > > Yeah, I somewhat dropped the ball on this, after some iterations and a > partial merge. Will put it on my list to revive this. I was hoping we made some steps, but I did see [1] as well and it is possible that I am missing some discussion, but it is starting to get W=2 builds warnings noisy enough to start interfering with discovering real problems as we keep adding new stuff in.. Just wondering... [1] https://lore.kernel.org/linux-devicetree/cal_jsq++dyikg9smqgx9fapdjnvrezcxnb0y5uh-5_2gbzt...@mail.gmail.com/ [2] https://pastebin.ubuntu.com/p/ns6hPCBxVM/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v5 0/3] arm64: Add TI AM65x-based IOT2050 boards
On Thu, 11 Mar 2021 15:33:40 +0100, Jan Kiszka wrote: > Changes in v4: > - dropped spidev node > - rebased over ti-k3-dts-next > > Jan > > Jan Kiszka (3): > dt-bindings: Add Siemens vendor prefix > dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards > arm64: dts: ti: Add support for Siemens IOT2050 boards > > [...] Hi Jan Kiszka, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/3] dt-bindings: Add Siemens vendor prefix commit: 61a9114b891f0a4e5e4bee2bc93745343234973e [2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards commit: 807a2b86269e6eea9ac9d4cd3aafccf8478449ee [3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards commit: e180f76d06412bb412ab675dadeb8c2b64da1dcf All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 15:36-20210311, Jan Kiszka wrote: > On 11.03.21 15:21, Nishanth Menon wrote: > > On 15:14-20210311, Jan Kiszka wrote: > > > > [...] > > > >>> > >>> See [1] compare the compatibles against > >>> Documentation/devicetree/bindings -> I think you should describe what > >>> your hardware really is though. > >> > >> This SPI bus is routed to an Arduino connector. By default, userspace > >> (e.g. mraa) takes ownership and adds the desired logic for what is being > >> connected. We have no idea what shield or other extension the user adds, > >> though. > > > > overlays look like the right approach for variable systems like these. > > It is not exactly plug and play.. but it does provide a level of > > flexibility that is helpful. > > Yes, that's for extensions which have kernel drivers. The default model > here is userspace, though. Will add as a separate patch to our queue for > now. My colleagues did some checkups and pulled up a few thread on spidev of potential interests.. See: https://patchwork.kernel.org/project/spi-devel-general/patch/1427499742-26916-1-git-send-email-broo...@kernel.org/ https://yurovsky.github.io/2016/10/07/spidev-linux-devices.html etc... I'd split the spidev node alone as an addendum indicate the checkpatch warning, describe the details and loop in spidev list, Mark, et.al. to discuss the direction. I am hoping we can get this resolved or get a direction for .13-rc1 But that said, I see some examples such as for i in `git grep ".compatible" drivers/spi/spidev.c|grep =|cut -d '=' -f2|cut -d ' ' -f2`; do git grep $i Documentation/devicetree/bindings/; done Documentation/devicetree/bindings/spi/spi-mux.yaml:compatible = "lineartechnology,ltc2488"; Documentation/devicetree/bindings/misc/ge-achc.txt:- compatible : Should be "ge,achc" Documentation/devicetree/bindings/misc/ge-achc.txt: compatible = "ge,achc"; Documentation/devicetree/bindings/misc/lwn-bk4.txt:- compatible : Should be "lwn,bk4" Documentation/devicetree/bindings/misc/lwn-bk4.txt: compatible = "lwn,bk4"; So, the shield could be hosting one of those say ge,achc or maybe lwn,bk4 ?- will probably be good to document the dts is for such a configuration, though it is possible that such a configuration might work for others? I agree with Mark that "dt should indicate specific hardware" and we should constraint the definition in such a scope? [...] > > > >> Are we talking about spidev here? Then let's drop that node, but I do > >> need to know how to describe spidev properly > > > > yes - the spidev is my problem. can you drop the node and repost? i cant > > locally modify and hope it works. > > > > Done. Thanks, I will try and pick up the v5 later today - need to redo my sanity checkups. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 15:14-20210311, Jan Kiszka wrote: [...] > > > > See [1] compare the compatibles against > > Documentation/devicetree/bindings -> I think you should describe what > > your hardware really is though. > > This SPI bus is routed to an Arduino connector. By default, userspace > (e.g. mraa) takes ownership and adds the desired logic for what is being > connected. We have no idea what shield or other extension the user adds, > though. overlays look like the right approach for variable systems like these. It is not exactly plug and play.. but it does provide a level of flexibility that is helpful. [..] > The problem here is not simple txt->yml conversion: There is no official > binding for spidev yet, just existing users and the driver waiting for them. > I think we should discuss in the spidev list to get it resolved. > > Thanks.. While it might help me personally to get some on my internal > > farm, it might be good to get them on kernelci as well on the longer > > run. > > > > Will keep that on the radar. I definitely want to get it into the CIP > LAVA lab which is testing LTS as well. Cool. > Are we talking about spidev here? Then let's drop that node, but I do > need to know how to describe spidev properly yes - the spidev is my problem. can you drop the node and repost? i cant locally modify and hope it works. > > Or is it about those other warnings coming from your dtsi files, now > being surfaced? If you can tell me how to resolve them, I can write patches. I will look at the warnings later today.. I dont think they are triggered by the board dts. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM
On Tue, 9 Mar 2021 21:53:15 +0530, Aswath Govindraju wrote: > Add pinmux details and device tree node for the EEPROM attached to SPI0 > module in main domain. Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM commit: 4fb6c04683aa5b45f3876f45465e13265e09eb56 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 0/3] Enable 8D-8D-8D mode on J721E, J7200, AM654
On Fri, 5 Mar 2021 21:09:23 +0530, Pratyush Yadav wrote: > Now that the OSPI controller driver and the SPI NOR core have support > for 8D-8D-8D mode, the device tree can be updated to allow Octal DTR > transactions. > > Pratyush Yadav (3): > arm64: dts: ti: k3-j721e-som-p0: Enable 8D-8D-8D mode on OSPI > arm64: dts: ti: am654-base-board: Enable 8D-8D-8D mode on OSPI > arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0 > > [...] Hi Pratyush Yadav, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/3] arm64: dts: ti: k3-j721e-som-p0: Enable 8D-8D-8D mode on OSPI commit: 4c20ee99dd1a36ab89c6a8c51ed25e9328d8a8cc [2/3] arm64: dts: ti: am654-base-board: Enable 8D-8D-8D mode on OSPI commit: 7c172b30a540644fa53051e947d6712be5d6d6ce [3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0 commit: efbdf2e9183bd5e75c64d251c6b673ca61ea01b3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
On Fri, 5 Mar 2021 11:11:04 +0530, Aswath Govindraju wrote: > According to latest errata of J721e [1], HS400 mode is not supported > in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 > subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v > in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. > > Also, update the itap delay values for all the MMCSD subsystems according > the latest J721e data sheet[2] > > [...] Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems commit: eb8f6194e8074d7b00642dd75cf04d13e1b218e4 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
On Sat, 20 Feb 2021 13:49:51 +0100, Jan Kiszka wrote: > Add the DT entry for a watchdog based on RTI1. > > On SR1.0 silicon, it requires additional firmware on the MCU R5F cores > to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As > this firmware will also lock the power domain to protect it against > premature shutdown, mark it shared. Hi Jan Kiszka, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry commit: 6674a90bb141496f56ce840c22f2f2ddccc5d397 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 14:44-20210311, Jan Kiszka wrote:
> On 11.03.21 14:17, Nishanth Menon wrote:
> > On 10:37-20210310, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >> + spidev@0 {
> >> + compatible = "rohm,dh2228fv";
> >> + spi-max-frequency = <2000>;
> >> + reg = <0>;
> >
> > Jan,
> >
> > As part of my final sanity checks, I noticed that we missed this: is a
> > checkpatch warning
> >
> > WARNING: DT compatible string "rohm,dh2228fv" appears un-documented --
> > check ./Documentation/devicetree/bindings/
> > #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> > compatible = "rohm,dh2228fv";
> >
> > I cannot pick up nodes that are'nt documented as yaml in
> > Documentation/devicetree
> >
> > I know this is irritating to find such nodes that already have previous
> > users and the person coming last gets to deal with "new rules".. but
> > sorry for catching this so late.
> >
> > Here are the options that come to mind:
> >
> > option 1) - drop the node and resubmit.
> >
> > option 2) - get the documentation into linux master tree and then submit
> > the patches.
> >
>
> As you said, I'm not setting a precedence here:
>
> arch/arm/boot/dts/imx28-cfa10049.dts: compatible =
> "rohm,dh2228fv";
> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible =
> "rohm,dh2228fv";
> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>
> Was just just never documented as binding? Or why is no one allowed to
> use this anymore? What is to be used instead for spidev?
See [1] compare the compatibles against
Documentation/devicetree/bindings -> I think you should describe what
your hardware really is though.
Unfortunately devicetree migration has been far from being smooth.. it
was like chewing an elephant - linux community had to attack it in
pieces..
Yes - it was unfortunately one of those cases where the driver support
was introduced long back and no binding was introduced at that time (it
was'nt mandatory then).. then we added a mandatory requirement that it
be documented in txt.. over years realized things are'nt great with
unstructured txt description of binding, now moving on converting
existing txt files to yaml and schemas to static check the dts...
evolution over the years, I guess.
I am on a fight internally as well to have all our legacy txt files
converted over to yaml.. and am having to put up a stance - see [2]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
[2]
https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
> >
> > I think we should just drop the node and resubmit - since this is a more
> > intrusive change and I don't have your platform handy, I am going to
> > suggest you make a call :(
>
> This breaks userspace here, and we would need to carry that node on top.
>
Uggh... that sucks.. but I think that would be lower tradeoff to make
than me (as it stands now) having to drop the patch series.
> BTW, I already brought up the topic internally to get you some boards
> for testing.
Thanks.. While it might help me personally to get some on my internal
farm, it might be good to get them on kernelci as well on the longer
run.
>
> I've done that and addressed all that I could (former patch 4). We
> import those from k3, and I don't feel confident how to resolve them.
> See also v1 of this patch.
Yeah - i noticed that upstream dt-schema has gotten even more stricter
even though the dts has remained the same.. I need to spend time in
digging at it.
At this point the only big kicker is the checkpatch stuff which I cant
let through - if i do that arnd will probably kick everything from my
PR out :( - which I cant do.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D
1736 249D
Re: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
On 19:11-20210311, Pratyush Yadav wrote:
> On 11/03/21 07:22AM, Nishanth Menon wrote:
> > On 21:43-20210305, Vignesh Raghavendra wrote:
> > >
> > >
> > > On 3/5/21 9:09 PM, Pratyush Yadav wrote:
> > > > TI J7200 has the Cadence OSPI controller for interfacing with OSPI
> > > > flashes. Add its node to allow using SPI flashes.
> > > >
> > > > Signed-off-by: Pratyush Yadav
> > > > ---
> > >
> > > Reviewed-by: Vignesh Raghavendra
> > >
> > >
> > >
> > > >
> > > > Notes:
> > > > Changes in v2:
> > > > - Do not force a pulldown on the DQS line because it already has a
> > > > pulldown resistor.
> > > >
> > > > .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 17 +
> > > > arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++
> > > > 2 files changed, 53 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > > > b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > > > index 359e3e8a8cd0..5408ec815d58 100644
> > > > --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > > > +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > > > @@ -269,6 +269,23 @@ hbmc: hyperbus@47034000 {
> > > > #size-cells = <1>;
> > > > mux-controls = <_mux 0>;
> > > > };
> > > > +
> > > > + ospi0: spi@4704 {
> > > > + compatible = "ti,am654-ospi";
> > > > + reg = <0x0 0x4704 0x0 0x100>,
> > > > + <0x5 0x 0x1 0x000>;
> > > > + interrupts = ;
> > > > + cdns,fifo-depth = <256>;
> > > > + cdns,fifo-width = <4>;
> > > > + cdns,trigger-address = <0x0>;
> > > > + clocks = <_clks 103 0>;
> > > > + assigned-clocks = <_clks 103 0>;
> > > > + assigned-clock-parents = <_clks 103 2>;
> > > > + assigned-clock-rates = <1>;
> > > > + power-domains = <_pds 103
> > > > TI_SCI_PD_EXCLUSIVE>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > };
> > > >
> > > > tscadc0: tscadc@4020 {
> > > > diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > > > b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > > > index a988e2ab2ba1..34724440171a 100644
> > > > --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > > > +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > > > @@ -100,6 +100,22 @@ J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (A8)
> > > > MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
> > > > J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
> > > > MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
> > > > >;
> > > > };
> > > > +
> > > > + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
> > > > + pinctrl-single,pins = <
> > > > + J721E_WKUP_IOPAD(0x, PIN_OUTPUT, 0) /*
> > > > MCU_OSPI0_CLK */
> > > > + J721E_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0) /*
> > > > MCU_OSPI0_CSn0 */
> > > > + J721E_WKUP_IOPAD(0x000c, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D0 */
> > > > + J721E_WKUP_IOPAD(0x0010, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D1 */
> > > > + J721E_WKUP_IOPAD(0x0014, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D2 */
> > > > + J721E_WKUP_IOPAD(0x0018, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D3 */
> > > > + J721E_WKUP_IOPAD(0x001c, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D4 */
> > > > + J721E_WKUP_IOPAD(0x0020, PIN_INPUT, 0) /*
> > > > MCU_OSPI0_D5 */
> > > > + J721E_WKUP_IOPAD(0x
Re: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
On 21:43-20210305, Vignesh Raghavendra wrote:
>
>
> On 3/5/21 9:09 PM, Pratyush Yadav wrote:
> > TI J7200 has the Cadence OSPI controller for interfacing with OSPI
> > flashes. Add its node to allow using SPI flashes.
> >
> > Signed-off-by: Pratyush Yadav
> > ---
>
> Reviewed-by: Vignesh Raghavendra
>
>
>
> >
> > Notes:
> > Changes in v2:
> > - Do not force a pulldown on the DQS line because it already has a
> > pulldown resistor.
> >
> > .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 17 +
> > arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++
> > 2 files changed, 53 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > index 359e3e8a8cd0..5408ec815d58 100644
> > --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> > @@ -269,6 +269,23 @@ hbmc: hyperbus@47034000 {
> > #size-cells = <1>;
> > mux-controls = <_mux 0>;
> > };
> > +
> > + ospi0: spi@4704 {
> > + compatible = "ti,am654-ospi";
> > + reg = <0x0 0x4704 0x0 0x100>,
> > + <0x5 0x 0x1 0x000>;
> > + interrupts = ;
> > + cdns,fifo-depth = <256>;
> > + cdns,fifo-width = <4>;
> > + cdns,trigger-address = <0x0>;
> > + clocks = <_clks 103 0>;
> > + assigned-clocks = <_clks 103 0>;
> > + assigned-clock-parents = <_clks 103 2>;
> > + assigned-clock-rates = <1>;
> > + power-domains = <_pds 103 TI_SCI_PD_EXCLUSIVE>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > };
> >
> > tscadc0: tscadc@4020 {
> > diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > index a988e2ab2ba1..34724440171a 100644
> > --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> > @@ -100,6 +100,22 @@ J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (A8)
> > MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
> > J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
> > MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
> > >;
> > };
> > +
> > + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
> > + pinctrl-single,pins = <
> > + J721E_WKUP_IOPAD(0x, PIN_OUTPUT, 0) /*
> > MCU_OSPI0_CLK */
> > + J721E_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0) /*
> > MCU_OSPI0_CSn0 */
> > + J721E_WKUP_IOPAD(0x000c, PIN_INPUT, 0) /* MCU_OSPI0_D0
> > */
> > + J721E_WKUP_IOPAD(0x0010, PIN_INPUT, 0) /* MCU_OSPI0_D1
> > */
> > + J721E_WKUP_IOPAD(0x0014, PIN_INPUT, 0) /* MCU_OSPI0_D2
> > */
> > + J721E_WKUP_IOPAD(0x0018, PIN_INPUT, 0) /* MCU_OSPI0_D3
> > */
> > + J721E_WKUP_IOPAD(0x001c, PIN_INPUT, 0) /* MCU_OSPI0_D4
> > */
> > + J721E_WKUP_IOPAD(0x0020, PIN_INPUT, 0) /* MCU_OSPI0_D5
> > */
> > + J721E_WKUP_IOPAD(0x0024, PIN_INPUT, 0) /* MCU_OSPI0_D6
> > */
> > + J721E_WKUP_IOPAD(0x0028, PIN_INPUT, 0) /* MCU_OSPI0_D7
> > */
> > + J721E_WKUP_IOPAD(0x0008, PIN_INPUT, 0) /*
> > MCU_OSPI0_DQS */
> > + >;
> > + };
> > };
> >
> > _pmx0 {
> > @@ -235,3 +251,23 @@ exp_som: gpio@21 {
> > "GPIO_LIN_EN", "CAN_STB";
> > };
> > };
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_fss0_ospi0_pins_default>;
> > +
> > + flash@0{
> > + compatible = "jedec,spi-nor";
> > + reg = <0x0>;
> > + spi-tx-bus-width = <8>;
> > + spi-rx-bus-width = <8>;
> > + spi-max-frequency = <2500>;
> > + cdns,tshsl-ns = <60>;
> > + cdns,tsd2d-ns = <60>;
> > + cdns,tchsh-ns = <60>;
> > + cdns,tslch-ns = <60>;
> > + cdns,read-delay = <4>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + };
I see this:
+/workdir/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dt.yaml: flash@0:
'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns',
'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
And that is because
Documentation/devicetree/bindings/spi/cadence-quadspi.txt is not
converted to yaml. Following the new stringent rules, yaml please?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D
1736 249D
Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 10:37-20210310, Jan Kiszka wrote:
> From: Jan Kiszka
> + spidev@0 {
> + compatible = "rohm,dh2228fv";
> + spi-max-frequency = <2000>;
> + reg = <0>;
Jan,
As part of my final sanity checks, I noticed that we missed this: is a
checkpatch warning
WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check
./Documentation/devicetree/bindings/
#629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
compatible = "rohm,dh2228fv";
I cannot pick up nodes that are'nt documented as yaml in
Documentation/devicetree
I know this is irritating to find such nodes that already have previous
users and the person coming last gets to deal with "new rules".. but
sorry for catching this so late.
Here are the options that come to mind:
option 1) - drop the node and resubmit.
option 2) - get the documentation into linux master tree and then submit
the patches.
I think we should just drop the node and resubmit - since this is a more
intrusive change and I don't have your platform handy, I am going to
suggest you make a call :(
Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
see more than a few warnings there which may need some closer look.
A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/
PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
I have been using my script to verify with kpv -C -V -n num_patches and
then digging through the logs.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D
1736 249D
Re: [PATCH] arm64: dts: ti: k3-am65-mcu: Add RTI watchdog entry
On 19:36-20210310, Bajjuri, Praneeth wrote:
>
>
> On 2/20/2021 6:49 AM, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > Add the DT entry for a watchdog based on RTI1.
> >
> > On SR1.0 silicon, it requires additional firmware on the MCU R5F cores
> > to handle the expiry, e.g. https://github.com/siemens/k3-rti-wdt. As
> > this firmware will also lock the power domain to protect it against
> > premature shutdown, mark it shared.
> >
> > Signed-off-by: Jan Kiszka
>
> Acked-by: Praneeth Bajjuri
>
> > ---
> > arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> > b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> > index 7454c8cec0cc..903796bf7d64 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> > +++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
> > @@ -308,4 +308,13 @@ mcu_r5fss0_core1: r5f@4140 {
> > ti,loczrama = <1>;
> > };
> > };
> > +
> > + mcu_rti1: rti@4061 {
Jan, I was about to pick up the patches and was running through
my sanity checks and the following caught my eye with dtbs_check
(dtschema is at 2021.2.1) test against next-20210311
/workdir/arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: rti@4061:
$nodename:0: 'rti@4061' does not match '^watchdog(@.*|-[0-9a-f])?$'
Please use watchdog@4061 instead of rti@4061
Since this is a minor change, I have done this change locally. let me
know if you have an issue and I can drop it off my branch for a new
version.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D
1736 249D
Re: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
On 21:09-20210305, Pratyush Yadav wrote: > TI J7200 has the Cadence OSPI controller for interfacing with OSPI > flashes. Add its node to allow using SPI flashes. > > Signed-off-by: Pratyush Yadav > --- > > Notes: > Changes in v2: > - Do not force a pulldown on the DQS line because it already has a > pulldown resistor. > > .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 17 + > arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++ > 2 files changed, 53 insertions(+) I see this with dtbs_check on v5.12-rc2: /workdir/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the regexes: '^partition@', 'pinctrl-[0-9]+' -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 0/2] AM64: Add support for GPIO
On 21:20-20210309, Aswath Govindraju wrote: > Hi Nishanth, > > On 09/03/21 8:13 pm, Nishanth Menon wrote: > > On 16:59-20210304, Aswath Govindraju wrote: > >> The following series of patches adds support for gpio on AM642 evm/sk. > >> > >> Changes since v1: > >> - Added DT for gpio subsystem present in MCU domain > >> - reserved the mcu gpio for firmware usage > >> > >> This series of patches depend on, > >> https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039 > >> https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439153 > >> > >> > >> Aswath Govindraju (2): > >> arm64: dts: ti: k3-am64: Add GPIO DT nodes > >> arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware > >> usage > >> > >> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 > >> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 27 ++ > >> arch/arm64/boot/dts/ti/k3-am642-evm.dts | 5 +++ > >> arch/arm64/boot/dts/ti/k3-am642-sk.dts | 5 +++ > >> 4 files changed, 82 insertions(+) > >> > >> -- > >> 2.17.1 > >> > > > > > > Based on your offline comment: > > - > > > > On going through the bootlogs before posting for I found the following > > errors, > > > > [1.091117] davinci_gpio 601000.gpio: IRQ index 2 not found > > [1.101522] davinci_gpio 601000.gpio: error -ENXIO: IRQ not populated > > > > Some issues in allocating interrupts in case of main_gpio1. I > > accumulated the gpio with interrupt numbers. I'll try to debug the > > reason behind it and update you with its status. (bootlogs of ti-sdk, > > also have this error). > > > > - > > > > I am going to drop this off my queue, please update if the fixup is some > > system configuration error or repost with fix. > > > > This is expected to be a fixup in the system configuration and not a bug > in the patch series. So, can you please have these patches in your queue > ? I'll soon post the test results indicating the functioning of GPIOs. Thanks for clarifying. I will wait till the test results are posted. Thanks in advance for digging into this and detailed testing. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 16:22-20210309, Jan Kiszka wrote: > On 09.03.21 16:10, Nishanth Menon wrote: > > On 09:38-20210309, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> Add support for two Siemens SIMATIC IOT2050 variants, Basic and > >> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus > >> differ in their number of cores and availability of security features. > >> Furthermore the Advanced version comes with more RAM, an eMMC and a few > >> internal differences. > >> > >> Based on original version by Le Jin. > >> > >> Link: > >> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html > >> Link: https://github.com/siemens/meta-iot2050 > >> Signed-off-by: Jan Kiszka > >> Reviewed-by: Vignesh Raghavendra > >> --- > > > > Jan, > > > > I am not sure if > > https://lore.kernel.org/linux-arm-kernel/20210304160712.8452-2-s-a...@ti.com/ > > is going to impact your platform. I am planning on picking that series up > > today. > > might be good to test against tomorrow's next - running through my basic > > tests right now before committing to the ICSS-G nodes being picked up. > > > > If you could repost after testing against tomorrow's next, it will > > probably be better. > > Thanks, I was already on CC. That series does not affect the board > features as configured in this patch. However, we are eagerly awaiting > ISCCG and then PRU Ethernet support in upstream as this is used on our > boards, with both SR1.0 and (upcoming) SR2.0. Cool, thanks. > > However, I can update [1] with that series and retest our staging > integration. But as you can see from the topmost commit, it is > constantly shaking as upstreaming goes on. Yep, hopefully things should settle down soon-ish, I hope. Thanks for the link. > > Jan > > [1] https://github.com/siemens/linux/commits/jan/iot2050 > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 09:38-20210309, Jan Kiszka wrote: > From: Jan Kiszka > > Add support for two Siemens SIMATIC IOT2050 variants, Basic and > Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus > differ in their number of cores and availability of security features. > Furthermore the Advanced version comes with more RAM, an eMMC and a few > internal differences. > > Based on original version by Le Jin. > > Link: > https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html > Link: https://github.com/siemens/meta-iot2050 > Signed-off-by: Jan Kiszka > Reviewed-by: Vignesh Raghavendra > --- Jan, I am not sure if https://lore.kernel.org/linux-arm-kernel/20210304160712.8452-2-s-a...@ti.com/ is going to impact your platform. I am planning on picking that series up today. might be good to test against tomorrow's next - running through my basic tests right now before committing to the ICSS-G nodes being picked up. If you could repost after testing against tomorrow's next, it will probably be better. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM
On 20:18-20210309, Vignesh Raghavendra wrote:
>
>
> On 3/1/21 11:35 AM, Aswath Govindraju wrote:
> > Add pinmux details and device tree node for the EEPROM attached to SPI0
> > module in main domain.
> >
> > Signed-off-by: Aswath Govindraju
> > ---
>
> Reviewed-by: Vignesh Raghavendra
>
> Regards
> Vignesh
>
> >
> > This patch depends on,
> > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210301055109.17626-3-a-govindr...@ti.com/
Can you drop this dependency and rebase on top of my -next branch or
linux-next ? I am not able to apply the patch directly and would like to
avoid hand modifying the patch.
> >
> > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> > b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> > index bfd849a29655..bc5bd7f896ab 100644
> > --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> > +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> > @@ -139,6 +139,15 @@
> > AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
> > USB0_DRVVBUS */
> > >;
> > };
> > +
> > + main_spi0_pins_default: main-spi0-pins-default {
> > + pinctrl-single,pins = <
> > + AM64X_IOPAD(0x0210, PIN_INPUT, 0) /* (D13) SPI0_CLK */
> > + AM64X_IOPAD(0x0208, PIN_OUTPUT, 0) /* (D12) SPI0_CS0 */
> > + AM64X_IOPAD(0x0214, PIN_OUTPUT, 0) /* (A13) SPI0_D0 */
> > + AM64X_IOPAD(0x0218, PIN_INPUT, 0) /* (A14) SPI0_D1 */
> > + >;
> > + };
> > };
> >
> > _uart0 {
> > @@ -245,6 +254,19 @@
> > pinctrl-0 = <_usb0_pins_default>;
> > };
> >
> > +_spi0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_spi0_pins_default>;
> > + ti,pindir-d0-out-d1-in = <1>;
> > + eeprom@0 {
> > + compatible = "microchip,93lc46b";
> > + reg = <0>;
> > + spi-max-frequency = <100>;
> > + spi-cs-high;
> > + data-size = <16>;
> > + };
> > +};
> > +
> > {
> > /* emmc */
> > bus-width = <8>;
> >
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v2 0/4] arm64: dts: ti: am642x: add CPSW3g DT nodes
On 23:10-20210304, Grygorii Strashko wrote: > Hi > > This series adds corresponding AM642x CPSW3g nodes required to enable > networking > on TI am642-evm/sk platforms and adds required pinmux/PHY nodes in > corresponding > board files. > > Kernel Boot Log: > EVM: https://pastebin.ubuntu.com/p/6Qkbw35Jg3/ > SK: https://pastebin.ubuntu.com/p/Pd3xxP9J9K/ > > Changes in v2: > - minor comment fixed > - add Reviewed-by: Lokesh Vutla > > v1: https://lore.kernel.org/patchwork/cover/1389305/ > > Grygorii Strashko (1): > arm64: dts: ti: k3-am64-main: add main CPTS entry > Thanks, applied to ti-k3-dts-next. PS: my -next branches are being rebased to 5.12-rc2 to keep a future bisect clean. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 0/2] AM64: Add support for GPIO
On 16:59-20210304, Aswath Govindraju wrote: > The following series of patches adds support for gpio on AM642 evm/sk. > > Changes since v1: > - Added DT for gpio subsystem present in MCU domain > - reserved the mcu gpio for firmware usage > > This series of patches depend on, > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039 > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439153 > > > Aswath Govindraju (2): > arm64: dts: ti: k3-am64: Add GPIO DT nodes > arm64: dts: ti: k3-am642: reserve gpio in mcu domain for firmware > usage > > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 > arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 27 ++ > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 5 +++ > arch/arm64/boot/dts/ti/k3-am642-sk.dts | 5 +++ > 4 files changed, 82 insertions(+) > > -- > 2.17.1 > Based on your offline comment: - On going through the bootlogs before posting for I found the following errors, [1.091117] davinci_gpio 601000.gpio: IRQ index 2 not found [1.101522] davinci_gpio 601000.gpio: error -ENXIO: IRQ not populated Some issues in allocating interrupts in case of main_gpio1. I accumulated the gpio with interrupt numbers. I'll try to debug the reason behind it and update you with its status. (bootlogs of ti-sdk, also have this error). - I am going to drop this off my queue, please update if the fixup is some system configuration error or repost with fix. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 09:38-20210309, Jan Kiszka wrote: > From: Jan Kiszka > > Add support for two Siemens SIMATIC IOT2050 variants, Basic and > Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus > differ in their number of cores and availability of security features. > Furthermore the Advanced version comes with more RAM, an eMMC and a few > internal differences. > > Based on original version by Le Jin. > > Link: > https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html > Link: https://github.com/siemens/meta-iot2050 > Signed-off-by: Jan Kiszka > Reviewed-by: Vignesh Raghavendra Jan, Could you post the full series as V3 please? it works better that way for b4 workflow for me. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 1/4] dt-bindings: Add Siemens vendor prefix
On 13:33-20210305, Rob Herring wrote: > On Thu, 11 Feb 2021 20:32:53 +0100, Jan Kiszka wrote: > > From: Jan Kiszka > > > > Add prefix for Siemens AG. > > > > Signed-off-by: Jan Kiszka > > --- > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > Acked-by: Rob Herring Rob, as the vendor prefix maintainer, do you see a problem if I carry this patch on my tree for -next? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
On 10:59-20210301, Kishon Vijay Abraham I wrote:
> On 25/02/21 6:57 pm, Aswath Govindraju wrote:
> > According to latest errata of J721e [1], HS400 mode is not supported
> > in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2
> > subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v
> > in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode.
> >
> > Also, update the itap delay values for all the MMCSD subsystems according
> > the latest J721e data sheet[2]
> >
> > [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf
> > [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf
> >
> > Fixes: e6dc10f200da ("arm64: dts: ti: j721e-main: Add SDHCI nodes")
> > Signed-off-by: Aswath Govindraju
>
> Reviewed-by: Kishon Vijay Abraham I
In some offline testing, I realized that the patch wont apply cleanly to
e6dc10f200da
cd48ce86a4d0c1ffec86aa46a26da993c9af5f53 might be a better candidate for
this - I will drop the patch from my queue in the morning, could you
update the patch with a new rev with appropriate Fixes?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D
1736 249D
Re: [PATCH v2 0/4] arm64: Add TI AM65x-based IOT2050 boards
On Thu, 11 Feb 2021 20:32:52 +0100, Jan Kiszka wrote: > Changes in v2: > - address board-specific issues found by kernel_verify_patch > - remove dead l2-cache node from iot2050-basic DT > - add binding for Siemens vendor prefix > - factor out board bindings into separate patch > - add missing device_type to common ti,am654-pcie-rc nodes > > [...] Hi Jan Kiszka, I have picked patch #4 in your series to the following to branch ti-k3-dts-next on [1]. Thank you! Rest of the series will have to be reposted *after* Rob Herring Acks the bindings (monitor status in queue [2]). [4/4] arm64: dts: ti: k3-am65-main: Add device_type to pcie*_rc nodes commit: 0d7571c36331aafce485fa105959b498c86615d7 I have picked patch #4 for the next kernel window for now, given it is a trivial fix. All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git [2] https://patchwork.ozlabs.org/project/devicetree-bindings/list/?param=3=2 -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
On Thu, 25 Feb 2021 18:57:36 +0530, Aswath Govindraju wrote: > According to latest errata of J721e [1], HS400 mode is not supported > in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 > subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v > in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. > > Also, update the itap delay values for all the MMCSD subsystems according > the latest J721e data sheet[2] > > [...] Hi Aswath Govindraju, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems commit: 9e3faed4dc176d06dc2bed5f16a33085af10fb1c All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/2] AM64: Add USB support
On 11:21-20210301, Aswath Govindraju wrote: > The following series of patches, add USB support for AM64. > > This series of patches depends on, > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039 > > Aswath Govindraju (2): > arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem > arm64: dts: ti: k3-am642-evm: Add USB support > > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 18 ++ > 2 files changed, 48 insertions(+) Please update the series to include SK as well. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3-am64-main: Add GPIO DT nodes
On 11:49-20210301, Aswath Govindraju wrote: > Add device tree nodes for GPIO modules and interrupt controller in main > domain. > > Signed-off-by: Aswath Govindraju > --- > > This patch depends on, > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039 > > > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 45 > 1 file changed, 45 insertions(+) > Please add MCU GPIO instance[1] as well. We may not use it in the evm, in which case disable it, but squash the domains into a single patch. [1] https://www.ti.com/lit/pdf/spruim2 -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] PM: AVS: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
On 16:48-20210224, Yang Li wrote: > Fix the following coccicheck warning: > ./drivers/soc/ti/smartreflex.c:820:0-23: WARNING: pm_sr_fops should be > defined with DEFINE_DEBUGFS_ATTRIBUTE > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/soc/ti/smartreflex.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c > index 5376f3d..b3c7460 100644 > --- a/drivers/soc/ti/smartreflex.c > +++ b/drivers/soc/ti/smartreflex.c > @@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val) > return 0; > } > > -DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, > +DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, > omap_sr_autocomp_store, "%llu\n"); > > static int omap_sr_probe(struct platform_device *pdev) > -- > 1.8.3.1 > LGTM. Reviewed-by: Nishanth Menon Though $subject might be soc: ti: smartreflex after the relocation to maintain consistency.. Upto santosh if he might want to locally change on applying the patch.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: Add support for Siemens IOT2050 boards
On 18:40-20210209, Jan Kiszka wrote: > On 09.02.21 15:44, Nishanth Menon wrote: > > Jan, > > > > A few quick scan comments below, you might need to post based off > > 5.12-rc1 once available.. > > > > Also, I see a bit of warnings with dtbs_check, which probably needs a > > little more digging into (pcie insists to get a device_type property, > > etc..) > > > > you could use kernel_patch_verify or > > https://github.com/nmenon/kernel_patch_verify/blob/master/Dockerbuild.md > > > > it throws up a report like this https://pastebin.ubuntu.com/p/SdkZr432z3/ > > > > Ok, will have a look - is that checkpatch on steroids? It does a bit more than execute checkpatch.. you can see the script https://github.com/nmenon/kernel_patch_verify/blob/master/kernel_patch_verify as well, but depending on files, for example: with dts, it does a dtbs_check, W=2 build, converts dtb to dts and back to dtb to wiggle out as many issues that people seem to hit against.. There are other solutions out there (patman etc).. in effect just a wrapper script around standard kernel based checkers.. > > > So, many of my comments below are just first pass parse of that log -> I > > usually do recommend building with W=2 and dtbs_check (with yamlint etc) > > to make sure things are a bit sane. Will be good to have additional > > eyes. > > > > On 11:21-20210209, Jan Kiszka wrote: > >> From: Jan Kiszka > >> > >> Add support for two Siemens SIMATIC IOT2050 variants, Basic and > >> Advanced. They are based on the TI AM6528 and AM6548 SOCs. > >> > >> Based on original version by Le Jin. > > > > Might be good to add links to the boards as well (if available), for > > future reference. > > > > Sure, though stability of links is not under my control. But I could > additionally drop https://github.com/siemens/meta-iot2050 here. hmm.. Something of a reference for folks may be 5 or 10 years down the road, as to answer "what is this board"? Upto you though.. [...] > >> diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > >> b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > >> new file mode 100644 > >> index ..de05937dbb60 > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > >> @@ -0,0 +1,649 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * Copyright (c) Siemens AG, 2018-2021 > >> + * > > > > Optional: might be nice to add a oneliner comment for reuse scope.. > > > > You mean something like "Common bits for IOT2050 basic and advanced boards"? Yeah, that'd help. [...] > >> + gpio-line-names = > >> + "wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0", > >> + "UART0-enable", "UART0-terminate", "", "WIFI-disable", > >> + "", "", "", "", "", "", "", "", "", "", > >> + "", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0", > >> + "IO1", "IO2", "", "IO3", "IO17-direction", > >> + "A5", "IO16-direction", "IO15-direction", > >> + "IO14-direction", "A3", > >> + "", "IO18-direction", "A4", "A2", "A1", > >> + "A0", "", "", "IO13", "IO11", > >> + "IO12", "IO10"; > > > > Any chance of intending this consistently? > > There is in fact a plan behind this way: I intended every 10 entries, to > ease counting the pins (and that proved to be valuable more than once > already). AAAh.. interesting.. as long as you find it useful, I am ok with it.. it was'nt obvious to me the first look.. [...] > >> diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts > >> b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts > >> new file mode 100644 > >> index ..bb9ab4fdd74e > >> --- /dev/null > >> +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts > >> @@ -0,0 +1,56 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * Copyrig
Re: [PATCH] arm64: dts: ti: Add support for Siemens IOT2050 boards
ames = "pcie-phy0";
> + reset-gpios = <_gpio0 27 GPIO_ACTIVE_HIGH>;
schema seems to want a device_type, and there seems to be some warnings
on serdes as well.. might be something to check up on..
> +};
> +
> +_ep {
> + status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
> b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
> new file mode 100644
> index ..bb9ab4fdd74e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Siemens AG, 2018-2021
> + *
Will be nice to explain the difference between basic and advanced dts.
Are they two different boards? looks like the basic is using a part spin
with a single cluster, perhaps? I guess links might help..
> + * Authors:
> + * Le Jin
> + * Jan Kiszka
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am65-iot2050-common.dtsi"
> +
> +/ {
> + compatible = "siemens,iot2050-basic", "ti,am654";
> + model = "SIMATIC IOT2050 Basic";
> +
> + memory@8000 {
> + device_type = "memory";
> + /* 1G RAM */
> + reg = <0x 0x8000 0x 0x4000>;
> + };
> +
> + cpus {
> + cpu-map {
> + /delete-node/ cluster1;
> + };
> + /delete-node/ cpu@100;
> + /delete-node/ cpu@101;
> + };
Personally, I'd prefer this (handling efuse spins in board files or
even overlays) instead of having to create 100s of dtsi per SoC for
every permutation & combination of TI efused devices and handle these
in board files. I do see examples of similar usage elsewhere in:
$ git grep /delete-node/ arch/arm64/boot/dts/
But, if someone has a different opinion, feel free to pipe up with a
reasonable way to prevent file explosion.
> +};
> +
> +/* eMMC */
> + {
> + status = "disabled";
> +};
> +
> +_pmx0 {
> + main_uart0_pins_default: main_uart0_pins_default {
> + pinctrl-single,pins = <
> + AM65X_IOPAD(0x01e4, PIN_INPUT, 0) /* (AF11) UART0_RXD
> */
> + AM65X_IOPAD(0x01e8, PIN_OUTPUT, 0) /* (AE11) UART0_TXD
> */
> + AM65X_IOPAD(0x01ec, PIN_INPUT, 0) /* (AG11)
> UART0_CTSn */
> + AM65X_IOPAD(0x01f0, PIN_OUTPUT, 0) /* (AD11)
> UART0_RTSn */
> + AM65X_IOPAD(0x0188, PIN_INPUT, 1) /* (D25) UART0_DCDn
> */
> + AM65X_IOPAD(0x018c, PIN_INPUT, 1) /* (B26) UART0_DSRn
> */
> + AM65X_IOPAD(0x0190, PIN_OUTPUT, 1) /* (A24) UART0_DTRn
> */
> + AM65X_IOPAD(0x0194, PIN_INPUT, 1) /* (E24) UART0_RIN
> */
> + >;
> + };
> +};
> +
> +_uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_uart0_pins_default>;
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
> b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
> new file mode 100644
> index ..aa1ef081ef22
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
> @@ -0,0 +1,57 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Siemens AG, 2018-2021
> + *
> + * Authors:
> + * Le Jin
> + * Jan Kiszka
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am65-iot2050-common.dtsi"
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: rm: remove unneeded semicolon
On 14:23-20210202, Yang Li wrote: > Eliminate the following coccicheck warning: > ./drivers/firmware/ti_sci.c:1762:2-3: Unneeded semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/firmware/ti_sci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c > index 235c7e7..5ae2040 100644 > --- a/drivers/firmware/ti_sci.c > +++ b/drivers/firmware/ti_sci.c > @@ -1759,7 +1759,7 @@ static int ti_sci_get_resource_range(const struct > ti_sci_handle *handle, > desc->num = resp->range_num; > desc->start_sec = resp->range_start_sec; > desc->num_sec = resp->range_num_sec; > - }; > + } > Uggh.. thanks.. Reviewed-by: Nishanth Menon Santosh: I know you have send your Soc fixes for merge, but will be great if you could pick for a future version, this is minor enough not to bother the stable, I think.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [GIT PULL 1/2] MAINTAINERS: Update to TI maintainer for v5.12
On 17:47-20210202, Arnd Bergmann wrote: > From: Arnd Bergmann > > On Sat, 30 Jan 2021 07:14:11 -0600, Nishanth Menon wrote: > > Please pull the following MAINTAINERS file update for v5.12 cycle. Made > > sense to send via ARM path since the main PR path was for TI platforms. > > This seems more appropriate to have in v5.11, I tend to fast-track > maintainer address changes as bug-fixes so future emails reach the > correct address. Ouch, my bad. Thanks for the headsup, will keep this in mind if (hopefully not), we need to do this in the future. > > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > > > are available in the Git repository at: > > > > [...] > > Merged into arm/fixes, thanks! > > merge commit: 6102f9e700bb3fee2f37756514885e7b14a70ef6 Thanks. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[GIT PULL 2/2] arm64: TI K3 DT updates for v5.12
Hi, Please pull the following device tree changes for v5.12 cycle. The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git tags/ti-k3-dt-for-v5.12 for you to fetch changes up to ae10ce938da59c19f303a91197ea7d664d1bc080: arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific (2021-01-28 08:51:18 -0600) Devicetree changes for TI K3 platforms for v5.12 merge window: - Common fixups: PMU compatible, MMC dtbs_check warnings squelch - J7200: R5F, PCIe, SERDES support - J721E: PCIE fixups Grygorii Strashko (1): arm64: dts: ti: k3: mmc: fix dtbs_check warnings Kishon Vijay Abraham I (6): arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for pcieX_ctrl arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node arm64: dts: ti: k3-j7200-main: Add PCIe device tree node arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe Nishanth Menon (1): arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific Suman Anna (3): arm64: dts: ti: k3-j7200: Add R5F cluster nodes arm64: dts: ti: k3-j7200-som-p0: Add mailboxes to R5Fs arm64: dts: ti: k3-j7200-som-p0: Add DDR carveout memory nodes for R5Fs arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 4 +- arch/arm64/boot/dts/ti/k3-am65.dtsi| 2 +- .../boot/dts/ti/k3-j7200-common-proc-board.dts | 38 + arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 161 - arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi| 42 +- arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi| 80 +- arch/arm64/boot/dts/ti/k3-j7200.dtsi | 2 +- arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 70 +++-- arch/arm64/boot/dts/ti/k3-j721e.dtsi | 2 +- 9 files changed, 336 insertions(+), 65 deletions(-) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D signature.asc Description: PGP signature
[GIT PULL 1/2] MAINTAINERS: Update to TI maintainer for v5.12
Hi, Please pull the following MAINTAINERS file update for v5.12 cycle. Made sense to send via ARM path since the main PR path was for TI platforms. The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git tags/ti-k3-maintainer-for-v5.12 for you to fetch changes up to 2672b94d730c4b69a17ce297dc3fa60b980e72dc: MAINTAINERS: Update my email address and maintainer level status (2021-01-12 07:47:13 -0600) Maintainer changes for TI for v5.12 merge window: - Tero switches to kernel.org address Tero Kristo (1): MAINTAINERS: Update my email address and maintainer level status MAINTAINERS | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D signature.asc Description: PGP signature
Re: [PATCH v3 2/2] arm64: dts: ti: k3-j7200: Add support for higher speed modes in MMCSD subsystems
On 20:50-20210127, Aswath Govindraju wrote: > Hi Nishanth, > > On 27/01/21 8:44 pm, Nishanth Menon wrote: > > On 20:38-20210127, Aswath Govindraju wrote: > >> The following speed modes are now supported in J7200 SoC, > >> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1]. > >> - UHS-I speed modes in MMCSD1 subsystem [1]. > >> > >> Add support for UHS-I modes by adding voltage regulator device tree nodes > >> and corresponding pinmux details, to power cycle and voltage switch cards. > >> Also set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1 > >> device tree nodes. > >> > >> [1] - section 12.3.6.1.1 MMCSD Features, in > >> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf > >> > >> Signed-off-by: Aswath Govindraju > >> --- > >> > >> performance test logs using EXT4 filesystem for eMMC HS400 speed mode, > >> https://pastebin.ubuntu.com/p/KFphDYXj93/ > >> > > > > 5.11.0-rc3-next-20210118-4 : > > > > a) could you make sure to post patches when you test with latest next? > > b) I see 2 patches in this series, but delta seems to be 4 patches, is > > there a dependency I am not aware of? > > > > There are no dependencies. The other two commits are completely > unrelated. From next time I will make sure that I use the latest next > and the delta matches. Thanks. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 1/2] dts: ti: k3-j7200-main: Add support for zeroth instance of GPIO subsystem
On 20:56-20210127, Aswath Govindraju wrote: > Hi Nishanth, > > On 27/01/21 8:42 pm, Nishanth Menon wrote: > > On 20:38-20210127, Aswath Govindraju wrote: > >> Add support for the zeroth instance of GPIO subsystem in the main domain. > >> > >> Signed-off-by: Aswath Govindraju > > > > > > I really dont want to pick up one patch per node instance. It is hard > > to scale and just creates a lot of noise. > > > > As the main goal of the patch series was to add support for higher speed > modes in MMC, I added only the required ones. If required I will send a > follow up patch to add the remaining GPIO nodes. I dont plan on picking this patch up in it's current form. please send a patch with all the gpio nodes added in as it makes no sense to split these out. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 2/2] arm64: dts: ti: k3-j7200: Add support for higher speed modes in MMCSD subsystems
On 20:38-20210127, Aswath Govindraju wrote: > The following speed modes are now supported in J7200 SoC, > - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1]. > - UHS-I speed modes in MMCSD1 subsystem [1]. > > Add support for UHS-I modes by adding voltage regulator device tree nodes > and corresponding pinmux details, to power cycle and voltage switch cards. > Also set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1 > device tree nodes. > > [1] - section 12.3.6.1.1 MMCSD Features, in > https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf > > Signed-off-by: Aswath Govindraju > --- > > performance test logs using EXT4 filesystem for eMMC HS400 speed mode, > https://pastebin.ubuntu.com/p/KFphDYXj93/ > 5.11.0-rc3-next-20210118-4 : a) could you make sure to post patches when you test with latest next? b) I see 2 patches in this series, but delta seems to be 4 patches, is there a dependency I am not aware of? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 1/2] dts: ti: k3-j7200-main: Add support for zeroth instance of GPIO subsystem
On 20:38-20210127, Aswath Govindraju wrote:
> Add support for the zeroth instance of GPIO subsystem in the main domain.
>
> Signed-off-by: Aswath Govindraju
I really dont want to pick up one patch per node instance. It is hard
to scale and just creates a lot of noise.
> ---
> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index 4cc2e9094d0e..75dffbb26d52 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -294,6 +294,23 @@
> pinctrl-single,function-mask = <0x>;
> };
>
> + main_gpio0: gpio@60 {
> + compatible = "ti,j721e-gpio", "ti,keystone-gpio";
> + reg = <0x0 0x0060 0x0 0x100>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-parent = <_gpio_intr>;
> + interrupts = <145>, <146>, <147>, <148>,
> + <149>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + ti,ngpio = <69>;
> + ti,davinci-gpio-unbanked = <0>;
> + power-domains = <_pds 105 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <_clks 105 0>;
> + clock-names = "gpio";
> + };
> +
> main_uart0: serial@280 {
> compatible = "ti,j721e-uart", "ti,am654-uart";
> reg = <0x00 0x0280 0x00 0x100>;
> --
> 2.17.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems
On 19:43-20210125, Aswath Govindraju wrote: > >>> Will also help to provide some verification log along with this. > >>> > >> > >> May I know what sort of logs would be best to provide. Would enumeration > >> logs during boot suffice ? > >> > >> Like this, > >> https://pastebin.ubuntu.com/p/v9NRV7GwMw/ ? > > > > That just says we detected the cards, no? > > I thought we had tests around this? Something including > > /sys/kernel/debug/mmc*/ios > > > > Something that demonstrates that this actually runs at the claimed > > speeds? That would be nice on linux-next, if possible as well.. > > > > Yes there are tests which confirm that claimed speeds are functional. I > will add them in the respin. Awesome. much appreciated. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems
On 19:12-20210125, Aswath Govindraju wrote: > Hi Nishanth, > > On 22/01/21 11:36 pm, Nishanth Menon wrote: > > On 21:54-20210122, Aswath Govindraju wrote: > >> The following series of patches > >> - adds support for HS200 and HS400 speed modes in MMCSD0 subsystem > >> - adds support for UHS-I speed modes in MMCSD1 subsystem > >> > >> Aswath Govindraju (2): > >> arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes > >> in MMCSD0 subsystem > >> arm64: dts: ti: k3-j7200-main: Add support for UHS-I modes in MMCSD1 > >> subsystem > > > > > > Just a curious couple of questions: > > Does squashing both the patches create a problem for understanding or a > > later bisect? I kind of thought these mostly go hand in hand between the > > instances, am I mistaken? > > > > Yes, they can be squashed. I post a respin doing this. Thanks. > > > Are there any otap delay params update needed or the defaults are good > > to go? > > > > The otap values are already up-to-date with the data sheet and don't > need updation. Thanks for the clarification. > > > Will also help to provide some verification log along with this. > > > > May I know what sort of logs would be best to provide. Would enumeration > logs during boot suffice ? > > Like this, > https://pastebin.ubuntu.com/p/v9NRV7GwMw/ ? That just says we detected the cards, no? I thought we had tests around this? Something including /sys/kernel/debug/mmc*/ios Something that demonstrates that this actually runs at the claimed speeds? That would be nice on linux-next, if possible as well.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/2] mmc: J7200: Add support for higher speed modes in MMCSD subsystems
On 21:54-20210122, Aswath Govindraju wrote: > The following series of patches > - adds support for HS200 and HS400 speed modes in MMCSD0 subsystem > - adds support for UHS-I speed modes in MMCSD1 subsystem > > Aswath Govindraju (2): > arm64: dts: ti: k3-j7200-main: Add support for HS200 and HS400 modes > in MMCSD0 subsystem > arm64: dts: ti: k3-j7200-main: Add support for UHS-I modes in MMCSD1 > subsystem Just a curious couple of questions: Does squashing both the patches create a problem for understanding or a later bisect? I kind of thought these mostly go hand in hand between the instances, am I mistaken? Are there any otap delay params update needed or the defaults are good to go? Will also help to provide some verification log along with this. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific
On Wed, 20 Jan 2021 13:51:45 -0600, Nishanth Menon wrote: > We can use CPU specific pmu configuration to expose the appropriate > CPU specific events rather than just the basic generic pmuv3 perf > events. Hi Nishanth Menon, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific commit: c72bf319f12803d8c8ddc3dbf54927380fc65b50 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arm64: dts: ti: k3: mmc: fix dtbs_check warnings
On Fri, 15 Jan 2021 21:30:16 +0200, Grygorii Strashko wrote: > Now the dtbs_check produces below warnings > sdhci@4f8: clock-names:0: 'clk_ahb' was expected > sdhci@4f8: clock-names:1: 'clk_xin' was expected > $nodename:0: 'sdhci@4f8' does not match '^mmc(@.*)?$' > > Fix above warnings by updating mmc DT definitions to follow > sdhci-am654.yaml bindings: > - rename sdhci dt nodes to 'mmc@' > - swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined > first Hi Grygorii Strashko, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/1] arm64: dts: ti: k3: mmc: fix dtbs_check warnings commit: 0cf73209ce2c60c5b717a02d9de10a6d524e08a6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH] arm64: dts: ti: k3*: Fixup PMU compatibility to be CPU specific
We can use CPU specific pmu configuration to expose the appropriate
CPU specific events rather than just the basic generic pmuv3 perf
events.
Reported-by: Sudeep Holla
Signed-off-by: Nishanth Menon
---
AM65: https://pastebin.ubuntu.com/p/TF2cCMySkt/
J721E: https://pastebin.ubuntu.com/p/jgGPNmNgG3/
J7200: https://pastebin.ubuntu.com/p/Kfc3VHHXNB/
Original report:
https://lore.kernel.org/linux-arm-kernel/20210119172412.smsjdo2sjzqi5vcn@bogus/
I have'nt split this patch up for fixes tag primarily because the
basic functionality works and this is an improvement than a critical
fixup to backport for older kernels.
arch/arm64/boot/dts/ti/k3-am65.dtsi | 2 +-
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 2 +-
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi
b/arch/arm64/boot/dts/ti/k3-am65.dtsi
index d84c0bc05023..a9fc1af03f27 100644
--- a/arch/arm64/boot/dts/ti/k3-am65.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -56,7 +56,7 @@ a53_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a53-pmu";
/* Recommendation from GIC500 TRM Table A.3 */
interrupts = ;
};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
index 66169bcf7c9a..b7005b803149 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi
@@ -114,7 +114,7 @@ a72_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a72-pmu";
interrupts = ;
};
diff --git a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
index cc483f7344af..f0587fde147e 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi
@@ -115,7 +115,7 @@ a72_timer0: timer-cl0-cpu0 {
};
pmu: pmu {
- compatible = "arm,armv8-pmuv3";
+ compatible = "arm,cortex-a72-pmu";
/* Recommendation from GIC500 TRM Table A.3 */
interrupts = ;
};
--
2.25.1.377.g2d2118b814c1
Re: [PATCH v11 1/7] dt-bindings: soc: mediatek: add mtk svs dt-bindings
On 08:47-20210112, Rob Herring wrote: > > + > > +maintainers: > > + - Matthias Brugger > > + - Kevin Hilman > > + - Nishanth Menon > > This should be someone that knows the h/w. Not who applies patches. > Perhaps you. Yes please, I would have no idea what to do with SVS patches. Thanks Rob for catching it. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] MAINTAINERS: Update my email address and maintainer level status
On Thu, 17 Dec 2020 15:07:21 +0200, Tero Kristo wrote: > My employment with TI is ending tomorrow, so update the email address > entry in the maintainers file. Also, I don't expect to spend that much > time with maintaining TI code anymore, so downgrade the status level to > odd fixes only on areas where I remain as the main contact point for > now, and move myself as secondary contact point where someone else has > taken over the maintainership. Hi Tero Kristo, I have applied the following to branch ti-k3-maintainer-next on [1]. Thank you! [1/1] MAINTAINERS: Update my email address and maintainer level status commit: 2672b94d730c4b69a17ce297dc3fa60b980e72dc All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Original patch reference [2]. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git [2] lore.kernel.org/r/20201217130721.23555-1-t-kri...@ti.com -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 0/6] PCI: J7200/J721E PCIe bindings
On Tue, 5 Jan 2021 20:44:15 +0530, Kishon Vijay Abraham I wrote: > Patch series adds DT nodes in order to get PCIe working in J7200. > Also includes couple of fixes for J721e. > > v1 of the patch series can be found @ [1] > v2 of the patch series can be found @ [2] > v3 of the patch series can be found @ [3] > > [...] Hi Kishon Vijay Abraham I, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/6] arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions commit: 0e3cfb868137cf7ced91d7dc709961000c0dae29 [2/6] arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for pcieX_ctrl commit: edb96779f3bcbe348f82b458077de0fb96118233 [3/6] arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node commit: 4c1b22a953d9f8af4d5c2f238fb74dc190d92f04 [4/6] arm64: dts: ti: k3-j7200-main: Add PCIe device tree node commit: 3276d9f53cf660f8ed60d98918170670d0ca6e54 [5/6] arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 commit: 429c0259f17f4fdf9c0beb5423b0c8f6c2ea2e8c [6/6] arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe commit: 3a6319df506f1a821abad2c71a580a2f7b78a304 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH V2] arm64: defconfig: Drop unused K3 SoC specific options
With [1] integrated and all users of the config symbols removed, we can safely remove the options from defconfig. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026170624.24241-1...@ti.com/ Signed-off-by: Nishanth Menon --- Could ARM SoC maintainers pick this up for the 5.11 cycle? unfortunately, this dropped through the cracks as dependencies were getting pulled together. I dont have any other patches for 5.11 rcs V1: https://lore.kernel.org/linux-arm-kernel/20201112215438.31432-1...@ti.com/ arch/arm64/configs/defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 838301650a79..a0bcf0201261 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -991,8 +991,6 @@ CONFIG_ARCH_TEGRA_210_SOC=y CONFIG_ARCH_TEGRA_186_SOC=y CONFIG_ARCH_TEGRA_194_SOC=y CONFIG_ARCH_TEGRA_234_SOC=y -CONFIG_ARCH_K3_AM6_SOC=y -CONFIG_ARCH_K3_J721E_SOC=y CONFIG_TI_SCI_PM_DOMAINS=y CONFIG_EXTCON_PTN5150=m CONFIG_EXTCON_USB_GPIO=y -- 2.29.2
Re: [PATCH v3 0/6] PCI: J7200/J721E PCIe bindings
On 21:01-20210104, Kishon Vijay Abraham I wrote: > Nishanth, > > On 04/01/21 8:21 pm, Nishanth Menon wrote: > > On 18:52-20210104, Kishon Vijay Abraham I wrote: > >> Nishanth, > >> > >> On 04/01/21 6:46 pm, Nishanth Menon wrote: > >>> On 18:40-20210104, Kishon Vijay Abraham I wrote: > >>>> Nishanth, > >>>> > >>>> On 04/01/21 6:29 pm, Nishanth Menon wrote: > >>>>> On 17:52-20210104, Kishon Vijay Abraham I wrote: > >>>>>> Patch series adds DT nodes in order to get PCIe working in J7200. > >>>>>> Also includes couple of fixes for J721e. > >>>>>> > >>>>>> v1 of the patch series can be found @ [1] > >>>>>> v2 of the patch series can be found @ [2] > >>>>>> > >>>>>> Changes from v2: > >>>>>> 1) Moved serdes_refclk node out of interconnect node and also replaced > >>>>>>"_" with "-" > >>>>>> > >>>>>> Changes from v1: > >>>>>> 1) Include only the device tree patches here (the binding patch is sent > >>>>>> separately) > >>>>>> 2) Include couple of patches that fixes J721E DTS. > >>>>>> > >>>>>> [1] -> http://lore.kernel.org/r/20201102101154.13598-1-kis...@ti.com > >>>>>> [2] -> http://lore.kernel.org/r/20201210130747.25436-1-kis...@ti.com > >>>>>> > >>>>>> Kishon Vijay Abraham I (6): > >>>>>> arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions > >>>>>> arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > >>>>>> pcieX_ctrl > >>>>>> arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node > >>>>>> arm64: dts: ti: k3-j7200-main: Add PCIe device tree node > >>>>>> arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 > >>>>>> arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe > >>>>>> > >>>>>> .../dts/ti/k3-j7200-common-proc-board.dts | 38 ++ > >>>>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 111 ++ > >>>>>> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 52 ++-- > >>>>>> 3 files changed, 157 insertions(+), 44 deletions(-) > >>>>> > >>>>> > >>>>> A bit confused on the dependency here. is there something merged into > >>>>> next-20210104 that makes this series ready for pickup? is there a way > >>>>> I can get a immutable tag for driver fixups to pull so that my dts > >>>>> next is not broken for PCIe (I am assuming looking at the series that > >>>>> this is probably not a backward compatible series?)? > >>>> > >>>> There are no driver changes for the basic J7200 PCIe support and the DT > >>>> bindings are already merged [1]. > >>>> > >>>> There are few errata fixes applicable for J721E which has to be removed > >>>> for J7200 but that depends on other patches to be merged [1] but that > >>>> doesn't impact j7200 functionality. > >>>> > >>>> [1] -> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml#n19 > >>>> [2] -> http://lore.kernel.org/r/20201230120515.2348-1-nad...@cadence.com > >>> > >>> So, Dropping stuff like "cdns,max-outbound-regions" (change from 16 to > >>> 32) will work on older kernels? Could you do a quick sanity check on the > >>> couple of "fixes" patches in this thread is not breaking functionality > >>> introduced in the older stable kernels? > >> > >> Okay, the driver changes are done such that it works with both old DT > >> and new DT however the newer DT will not work with old kernel. So I > >> think I should drop the "Fixes" tag in the DT patches. > > > > If there is a specific stable kernel version you might like to use, you > > could use that as well for those stable tags (see [1]) > > It's not a fix that might bother people (as it doesn't impact existing > functionality), so don't think it's a candidate for stable releases. OK. please repost without the fixes tag. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/6] PCI: J7200/J721E PCIe bindings
On 18:52-20210104, Kishon Vijay Abraham I wrote: > Nishanth, > > On 04/01/21 6:46 pm, Nishanth Menon wrote: > > On 18:40-20210104, Kishon Vijay Abraham I wrote: > >> Nishanth, > >> > >> On 04/01/21 6:29 pm, Nishanth Menon wrote: > >>> On 17:52-20210104, Kishon Vijay Abraham I wrote: > >>>> Patch series adds DT nodes in order to get PCIe working in J7200. > >>>> Also includes couple of fixes for J721e. > >>>> > >>>> v1 of the patch series can be found @ [1] > >>>> v2 of the patch series can be found @ [2] > >>>> > >>>> Changes from v2: > >>>> 1) Moved serdes_refclk node out of interconnect node and also replaced > >>>>"_" with "-" > >>>> > >>>> Changes from v1: > >>>> 1) Include only the device tree patches here (the binding patch is sent > >>>> separately) > >>>> 2) Include couple of patches that fixes J721E DTS. > >>>> > >>>> [1] -> http://lore.kernel.org/r/20201102101154.13598-1-kis...@ti.com > >>>> [2] -> http://lore.kernel.org/r/20201210130747.25436-1-kis...@ti.com > >>>> > >>>> Kishon Vijay Abraham I (6): > >>>> arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions > >>>> arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > >>>> pcieX_ctrl > >>>> arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node > >>>> arm64: dts: ti: k3-j7200-main: Add PCIe device tree node > >>>> arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 > >>>> arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe > >>>> > >>>> .../dts/ti/k3-j7200-common-proc-board.dts | 38 ++ > >>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 111 ++ > >>>> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 52 ++-- > >>>> 3 files changed, 157 insertions(+), 44 deletions(-) > >>> > >>> > >>> A bit confused on the dependency here. is there something merged into > >>> next-20210104 that makes this series ready for pickup? is there a way > >>> I can get a immutable tag for driver fixups to pull so that my dts > >>> next is not broken for PCIe (I am assuming looking at the series that > >>> this is probably not a backward compatible series?)? > >> > >> There are no driver changes for the basic J7200 PCIe support and the DT > >> bindings are already merged [1]. > >> > >> There are few errata fixes applicable for J721E which has to be removed > >> for J7200 but that depends on other patches to be merged [1] but that > >> doesn't impact j7200 functionality. > >> > >> [1] -> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml#n19 > >> [2] -> http://lore.kernel.org/r/20201230120515.2348-1-nad...@cadence.com > > > > So, Dropping stuff like "cdns,max-outbound-regions" (change from 16 to > > 32) will work on older kernels? Could you do a quick sanity check on the > > couple of "fixes" patches in this thread is not breaking functionality > > introduced in the older stable kernels? > > Okay, the driver changes are done such that it works with both old DT > and new DT however the newer DT will not work with old kernel. So I > think I should drop the "Fixes" tag in the DT patches. If there is a specific stable kernel version you might like to use, you could use that as well for those stable tags (see [1]) [1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/6] PCI: J7200/J721E PCIe bindings
On 18:40-20210104, Kishon Vijay Abraham I wrote: > Nishanth, > > On 04/01/21 6:29 pm, Nishanth Menon wrote: > > On 17:52-20210104, Kishon Vijay Abraham I wrote: > >> Patch series adds DT nodes in order to get PCIe working in J7200. > >> Also includes couple of fixes for J721e. > >> > >> v1 of the patch series can be found @ [1] > >> v2 of the patch series can be found @ [2] > >> > >> Changes from v2: > >> 1) Moved serdes_refclk node out of interconnect node and also replaced > >>"_" with "-" > >> > >> Changes from v1: > >> 1) Include only the device tree patches here (the binding patch is sent > >> separately) > >> 2) Include couple of patches that fixes J721E DTS. > >> > >> [1] -> http://lore.kernel.org/r/20201102101154.13598-1-kis...@ti.com > >> [2] -> http://lore.kernel.org/r/20201210130747.25436-1-kis...@ti.com > >> > >> Kishon Vijay Abraham I (6): > >> arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions > >> arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > >> pcieX_ctrl > >> arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node > >> arm64: dts: ti: k3-j7200-main: Add PCIe device tree node > >> arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 > >> arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe > >> > >> .../dts/ti/k3-j7200-common-proc-board.dts | 38 ++ > >> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 111 ++ > >> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 52 ++-- > >> 3 files changed, 157 insertions(+), 44 deletions(-) > > > > > > A bit confused on the dependency here. is there something merged into > > next-20210104 that makes this series ready for pickup? is there a way > > I can get a immutable tag for driver fixups to pull so that my dts > > next is not broken for PCIe (I am assuming looking at the series that > > this is probably not a backward compatible series?)? > > There are no driver changes for the basic J7200 PCIe support and the DT > bindings are already merged [1]. > > There are few errata fixes applicable for J721E which has to be removed > for J7200 but that depends on other patches to be merged [1] but that > doesn't impact j7200 functionality. > > [1] -> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml#n19 > [2] -> http://lore.kernel.org/r/20201230120515.2348-1-nad...@cadence.com So, Dropping stuff like "cdns,max-outbound-regions" (change from 16 to 32) will work on older kernels? Could you do a quick sanity check on the couple of "fixes" patches in this thread is not breaking functionality introduced in the older stable kernels? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 0/6] PCI: J7200/J721E PCIe bindings
On 17:52-20210104, Kishon Vijay Abraham I wrote: > Patch series adds DT nodes in order to get PCIe working in J7200. > Also includes couple of fixes for J721e. > > v1 of the patch series can be found @ [1] > v2 of the patch series can be found @ [2] > > Changes from v2: > 1) Moved serdes_refclk node out of interconnect node and also replaced >"_" with "-" > > Changes from v1: > 1) Include only the device tree patches here (the binding patch is sent > separately) > 2) Include couple of patches that fixes J721E DTS. > > [1] -> http://lore.kernel.org/r/20201102101154.13598-1-kis...@ti.com > [2] -> http://lore.kernel.org/r/20201210130747.25436-1-kis...@ti.com > > Kishon Vijay Abraham I (6): > arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions > arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > pcieX_ctrl > arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node > arm64: dts: ti: k3-j7200-main: Add PCIe device tree node > arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 > arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe > > .../dts/ti/k3-j7200-common-proc-board.dts | 38 ++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 111 ++ > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 52 ++-- > 3 files changed, 157 insertions(+), 44 deletions(-) A bit confused on the dependency here. is there something merged into next-20210104 that makes this series ready for pickup? is there a way I can get a immutable tag for driver fixups to pull so that my dts next is not broken for PCIe (I am assuming looking at the series that this is probably not a backward compatible series?)? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v3 1/6] arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions
On 17:52-20210104, Kishon Vijay Abraham I wrote:
> Cadence IP in J721E supports a maximum of 32 outbound regions. However
> commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device
> tree nodes") incorrectly added this as 16 outbound regions. Now that
> "cdns,max-outbound-regions" is an optional property with default value
> as 32, remove "cdns,max-outbound-regions" from endpoint DT node.
>
> Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree
> nodes")
^^ Is this a backward compatible fixup. If I were to apply this on
v5.10, wont we have a broken PCIe functionality? Drop the fixes if this
is not backward compatible fixup (unless ofcourse the driver fixup is
backported all the way back as well - I am assuming will be done in a
manner to preserve compatibility with older dtb?)
On master right now:
$ git grep "cdns,max-outbound-regions" .
Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml:
cdns,max-outbound-regions = <16>;
Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml:
cdns,max-outbound-regions:
Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml:
cdns,max-outbound-regions:
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:
cdns,max-outbound-regions = <16>;
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:
cdns,max-outbound-regions = <16>;
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:
cdns,max-outbound-regions = <16>;
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:
cdns,max-outbound-regions = <16>;
drivers/pci/controller/cadence/pcie-cadence-ep.c:
of_property_read_u32(np, "cdns,max-outbound-regions", >max_regions);
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 4
> 1 file changed, 4 deletions(-)
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] MAINTAINERS: Update my email address and maintainer level status
On 15:07-20201217, Tero Kristo wrote: > My employment with TI is ending tomorrow, so update the email address > entry in the maintainers file. Also, I don't expect to spend that much > time with maintaining TI code anymore, so downgrade the status level to > odd fixes only on areas where I remain as the main contact point for > now, and move myself as secondary contact point where someone else has > taken over the maintainership. > > Cc: Stephen Boyd > Cc: Michael Turquette > Cc: Nishanth Menon > Cc: Santosh Shilimkar > Cc: Borislav Petkov > Cc: Tony Luck > Signed-off-by: Tero Kristo > Signed-off-by: Tero Kristo Thanks Tero. Much appreciate your help and continued support.. Acked-by: Nishanth Menon > --- > MAINTAINERS | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f59ebd1eda3d..c362d8d9d316 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2615,8 +2615,8 @@ S: Maintained > F: drivers/power/reset/keystone-reset.c > > ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE > -M: Tero Kristo > M: Nishanth Menon > +M: Tero Kristo > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/arm/ti/k3.yaml > @@ -6465,9 +6465,9 @@ S: Maintained > F: drivers/edac/skx_*.[ch] > > EDAC-TI > -M: Tero Kristo > +M: Tero Kristo > L: linux-e...@vger.kernel.org > -S: Maintained > +S: Odd Fixes > F: drivers/edac/ti_edac.c > > EDIROL UA-101/UA-1000 DRIVER > @@ -17503,7 +17503,7 @@ F:drivers/iio/dac/ti-dac7612.c > > TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER > M: Nishanth Menon > -M: Tero Kristo > +M: Tero Kristo > M: Santosh Shilimkar > L: linux-arm-ker...@lists.infradead.org > S: Maintained > @@ -17647,9 +17647,9 @@ S:Maintained > F: drivers/clk/clk-cdce706.c > > TI CLOCK DRIVER > -M: Tero Kristo > +M: Tero Kristo > L: linux-o...@vger.kernel.org > -S: Maintained > +S: Odd Fixes > F: drivers/clk/ti/ > F: include/linux/clk/ti.h > > -- > 2.17.1 > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[GIT PULL] arm64: TI K3 SoC configs changes for v5.11
Hi, Here is a config changes for TI K3 SoCs. This is needed for booting the J721E board from an SD card. I do have a follow up cleanup patch[1] once drivers/soc/ti merges are in, which I think I will need to request later on. [1] https://lore.kernel.org/linux-arm-kernel/20201112215438.31432-1...@ti.com/ The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git tags/ti-k3-config-for-v5.11 for you to fetch changes up to 6b133f475a97a0839f02e3c0b937886b9adc2933: arm64: defconfig: Enable GPIO and I2C configs for TI's J721e platform (2020-11-12 11:50:18 -0600) ARM64 defconfig changes for TI K3 platforms for v5.11 merge window: - GPIO and I2C for J721E SD card support to be functional Faiz Abbas (1): arm64: defconfig: Enable GPIO and I2C configs for TI's J721e platform arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D signature.asc Description: PGP signature
[GIT PULL] arm64: TI K3 DT updates for v5.11
Hi, Please pull the following for TI K3 dts changes for v5.11 window. The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git tags/ti-k3-dt-for-v5.11 for you to fetch changes up to cd48ce86a4d0c1ffec86aa46a26da993c9af5f53: arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes (2020-11-30 07:12:54 -0600) Devicetree changes for TI K3 platforms for v5.11 merge window: - Standardized usage of "disabled" only in board.dts files, #interrupt-cells warning fixups, node format error fixes - J721E: R5F support, MMC/SD UHS mode added - AM654: R5F support, dss marked coherent, drop unused dma-ring-reset-quirk property - J7200: ADC support, Mailbox, hwspinlock Faiz Abbas (2): arm64: dts: ti: k3-j721e-main: Add output tap delay values arm64: dts: ti: k3-j721e-common-proc-board: Add support for SD card UHS modes Grygorii Strashko (1): arm64: dts: ti: k3-am65: ringacc: drop ti, dma-ring-reset-quirk Nishanth Menon (6): arm64: dts: ti: k3-am65*/j721e*: Fix unit address format error for dss node arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level arm64: dts: ti: am65/j721e: Fix up un-necessary status set to "okay" for crypto arm64: dts: ti: k3-am654-base-board: Fix up un-necessary status set to "okay" for USB arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved" Peter Ujfalusi (2): arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1 Sekhar Nori (1): arm64: dts: ti: k3: squelch warning about lack of #interrupt-cells Suman Anna (11): arm64: dts: ti: k3-am65-mcu: Add MCU domain R5F cluster node arm64: dts: ti: k3-am654-base-board: Add mailboxes to R5Fs arm64: dts: ti: k3-am654-base-board: Add DDR carveout memory nodes for R5Fs arm64: dts: ti: k3-am654-base-board: Reserve memory for IPC between R5F cores arm64: dts: ti: k3-j721e-mcu: Add MCU domain R5F cluster node arm64: dts: ti: k3-j721e-main: Add MAIN domain R5F cluster nodes arm64: dts: ti: k3-j721e-som-p0: Add mailboxes to R5Fs arm64: dts: ti: k3-j721e-som-p0: Add DDR carveout memory nodes for R5Fs arm64: dts: ti: k3-j7200-main: Add hwspinlock node arm64: dts: ti: k3-j7200-main: Add mailbox cluster nodes arm64: dts: ti: k3-j7200-som-p0: Add IPC sub-mailbox nodes Tomi Valkeinen (1): arm64: dts: ti: k3-am65: mark dss as dma-coherent Vignesh Raghavendra (1): arm64: dts: ti: k3-j7200-mcu-wakeup: Enable ADC support arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 13 +- arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi| 43 ++- arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 71 +-- .../boot/dts/ti/k3-j7200-common-proc-board.dts | 33 ++--- arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 114 + arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi| 19 +++ arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi| 94 ++ .../boot/dts/ti/k3-j721e-common-proc-board.dts | 83 - arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 135 +++-- arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi| 42 ++- arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi| 110 - 11 files changed, 682 insertions(+), 75 deletions(-) -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D signature.asc Description: PGP signature
Re: [PATCH] ARM: omap2plus_defconfig: drop unused POWER_AVS option
On 12:42-20201130, Andrey Zhizhikin wrote:
> Commit 785b5bb41b0a ("PM: AVS: Drop the avs directory and the
> corresponding Kconfig") moved AVS code to SOC-specific folders, and
> removed corresponding Kconfig from drivers/power, leaving original
> POWER_AVS config option enabled in omap2plus_defconfig file.
>
> Remove the option, which has no references in the tree anymore.
>
> Fixes: 785b5bb41b0a ("PM: AVS: Drop the avs directory and the corresponding
> Kconfig")
> Cc: Nishanth Menon
> Cc: Ulf Hansson
> Signed-off-by: Andrey Zhizhikin
> ---
> arch/arm/configs/omap2plus_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig
> b/arch/arm/configs/omap2plus_defconfig
> index 34793aabdb65..de3b7813a1ce 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -297,7 +297,6 @@ CONFIG_GPIO_TWL4030=y
> CONFIG_W1=m
> CONFIG_HDQ_MASTER_OMAP=m
> CONFIG_W1_SLAVE_DS250X=m
> -CONFIG_POWER_AVS=y
> CONFIG_POWER_RESET=y
> CONFIG_POWER_RESET_GPIO=y
> CONFIG_BATTERY_BQ27XXX=m
> --
> 2.17.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 1/2] arm64: defconfig: drop unused POWER_AVS option
On 11:27-20201130, Andrey Zhizhikin wrote:
> Commit 785b5bb41b0a ("PM: AVS: Drop the avs directory and the
> corresponding Kconfig") moved AVS code to SOC-specific folders, and
> removed corresponding Kconfig from drivers/power, leaving original
> POWER_AVS config option enabled in defconfig file.
>
> Remove the option, which has no references in the tree anymore.
>
> Fixes: 785b5bb41b0a ("PM: AVS: Drop the avs directory and the corresponding
> Kconfig")
> Cc: Nishanth Menon
> Cc: Ulf Hansson
> Signed-off-by: Andrey Zhizhikin
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 2/2] ARM: multi_v7_defconfig: drop unused POWER_AVS option
On 11:27-20201130, Andrey Zhizhikin wrote:
> Commit 785b5bb41b0a ("PM: AVS: Drop the avs directory and the
> corresponding Kconfig") moved AVS code to SOC-specific folders, and
> removed corresponding Kconfig from drivers/power, leaving original
> POWER_AVS config option enabled in multi_v7_defconfig file.
>
> Remove the option, which has no references in the tree anymore.
>
> Fixes: 785b5bb41b0a ("PM: AVS: Drop the avs directory and the corresponding
> Kconfig")
> Cc: Nishanth Menon
> Cc: Ulf Hansson
> Signed-off-by: Andrey Zhizhikin
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v2 0/2] arm64: dts: ti: k3-j7200-som/cpb: Correct i2c bus representations
On Fri, 20 Nov 2020 09:35:31 +0200, Peter Ujfalusi wrote: > Changes since v1: > - Added REviewed-by from Vignesh > - Comment block to explain main_i2c1 connection to CPB > > The main_i2c0 missed the ioexpander present on the SOM itself to control muxes > to route signals to CPB connectors. > > [...] Hi Peter Ujfalusi, I have applied the following to branch ti-k3-dts-next on [1]. Thank you! [1/2] arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM commit: b6633d778675a58fba1d7f795169da212a76231d [2/2] arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1 commit: 2eefbf5f862ed98a043917fa54c7a79a56ec08f6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. [1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
On 09:46-20201124, Sekhar Nori wrote: > On 24/11/20 6:51 AM, Nishanth Menon wrote: > > On 09:45-20201123, Sekhar Nori wrote: > >>>> The main reason I commented - is hope to get some clarification from DT > >>>> maintainers. > >>>> 90% of interrupt-controller nodes do not have #address-cells and I never > >>>> seen in in GPIO nodes > >>>> (most often is present in PCI and GIC nodes). > >>>> and nobody seems fixing it. So, if we are going to move this direction > >>>> it's reasonable to get clarification to be sure. > >>>> > >>>> And there is no "never" here - #address-cells always can be added if > >>>> really required. > >>> > >>> > >>> OK - as a GPIO node, but as an interrupt-controller node, I was > >>> looking at [1] and wondering if that was the precedence. > >>> > >>> Yes, will be good to get direction from the DT maintainers on this > >>> topic. > >> > >> Shall I respin this series with 2/4 dropped while we wait for decision > >> on this? > >> > >> #address-cells warnings on interrupt controller can perhaps be handled > >> all at once (there are many of those in existing DT anyway). > >> > >> GPIO is basic support and holds up many other modules (like MMC/SD). > > > > > > There are'nt too many new patches in my queue that depends on GPIO, I'd > > rather not introduce new warnings unless we are completely at a > > stalemate. I'd rather use this opportunity to understand where what we > > need to be doing. > GPIO was originally submitted as part of 8 patch series titled "[PATCH > 0/8] Add support for UHS modes in TI's J721e and J7200 boards" > > Rest of those patches need to be resubmitted after GPIO is accepted. > > Can you apply patch 1/4 at least. Its fairly non-controversial. It will > help reduce patch backlog and fix some warnings too. I see that Grygorii is suggesting 1,3,4 to be pulled in. can you repost with just the required patches alone and pick up the reviewed-bys? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
