[PATCH 7/7] dt-bindings: interconnect: qcom: msm8939: Fix example

2024-06-09 Thread Adam Skladowski
For now example list snoc_mm as children of bimc which is obviously
not valid, change example and include rest of nocs in it.

Fixes: 462baaf4c628 ("dt-bindings: interconnect: qcom: Fix and separate out 
MSM8939")
Signed-off-by: Adam Skladowski 
---
 .../bindings/interconnect/qcom,msm8939.yaml   | 22 ---
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml
index fd15ab5014fb..a77e6aa2fbee 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8939.yaml
@@ -56,19 +56,25 @@ examples:
   - |
 #include 
 
-snoc: interconnect@58 {
-compatible = "qcom,msm8939-snoc";
-reg = <0x0058 0x14000>;
-#interconnect-cells = <1>;
-};
-
 bimc: interconnect@40 {
 compatible = "qcom,msm8939-bimc";
 reg = <0x0040 0x62000>;
-#interconnect-cells = <1>;
+#interconnect-cells = <2>;
+};
+
+pcnoc: interconnect@50 {
+compatible = "qcom,msm8939-pcnoc";
+reg = <0x0050 0x11000>;
+#interconnect-cells = <2>;
+};
+
+snoc: interconnect@58 {
+compatible = "qcom,msm8939-snoc";
+reg = <0x0058 0x14080>;
+#interconnect-cells = <2>;
 
   snoc_mm: interconnect-snoc {
   compatible = "qcom,msm8939-snoc-mm";
-  #interconnect-cells = <1>;
+  #interconnect-cells = <2>;
   };
 };
-- 
2.45.1




[PATCH 6/7] interconnect: qcom: qcs404: Add regmaps and more bus descriptions

2024-06-09 Thread Adam Skladowski
Currently we are lacking descriptions of regmaps and buses,
provide them.

Signed-off-by: Adam Skladowski 
---
 drivers/interconnect/qcom/qcs404.c | 41 +++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/interconnect/qcom/qcs404.c 
b/drivers/interconnect/qcom/qcs404.c
index 91b2ccc56a33..f9b508a56588 100644
--- a/drivers/interconnect/qcom/qcs404.c
+++ b/drivers/interconnect/qcom/qcs404.c
@@ -1067,10 +1067,22 @@ static struct qcom_icc_node * const qcs404_bimc_nodes[] 
= {
[SLAVE_BIMC_SNOC] = _bimc_snoc,
 };
 
+static const struct regmap_config qcs404_bimc_regmap_config = {
+   .reg_bits = 32,
+   .reg_stride = 4,
+   .val_bits = 32,
+   .max_register = 0x8,
+   .fast_io = true,
+};
+
 static const struct qcom_icc_desc qcs404_bimc = {
-   .bus_clk_desc = _clk,
+   .type = QCOM_ICC_BIMC,
.nodes = qcs404_bimc_nodes,
.num_nodes = ARRAY_SIZE(qcs404_bimc_nodes),
+   .bus_clk_desc = _clk,
+   .regmap_cfg = _bimc_regmap_config,
+   .qos_offset = 0x8000,
+   .ab_coeff = 153,
 };
 
 static struct qcom_icc_node * const qcs404_pcnoc_nodes[] = {
@@ -1122,10 +1134,22 @@ static struct qcom_icc_node * const 
qcs404_pcnoc_nodes[] = {
[SLAVE_PCNOC_SNOC] = _pcnoc_snoc,
 };
 
+static const struct regmap_config qcs404_pcnoc_regmap_config = {
+   .reg_bits = 32,
+   .reg_stride = 4,
+   .val_bits = 32,
+   .max_register = 0x15080,
+   .fast_io = true,
+};
+
 static const struct qcom_icc_desc qcs404_pcnoc = {
-   .bus_clk_desc = _0_clk,
+   .type = QCOM_ICC_NOC,
.nodes = qcs404_pcnoc_nodes,
.num_nodes = ARRAY_SIZE(qcs404_pcnoc_nodes),
+   .bus_clk_desc = _0_clk,
+   .qos_offset = 0x7000,
+   .keep_alive = true,
+   .regmap_cfg = _pcnoc_regmap_config,
 };
 
 static struct qcom_icc_node * const qcs404_snoc_nodes[] = {
@@ -1151,10 +1175,21 @@ static struct qcom_icc_node * const qcs404_snoc_nodes[] 
= {
[SLAVE_LPASS] = _lpass,
 };
 
+static const struct regmap_config qcs404_snoc_regmap_config = {
+   .reg_bits = 32,
+   .reg_stride = 4,
+   .val_bits = 32,
+   .max_register = 0x23080,
+   .fast_io = true,
+};
+
 static const struct qcom_icc_desc qcs404_snoc = {
-   .bus_clk_desc = _1_clk,
+   .type = QCOM_ICC_NOC,
.nodes = qcs404_snoc_nodes,
.num_nodes = ARRAY_SIZE(qcs404_snoc_nodes),
+   .bus_clk_desc = _1_clk,
+   .qos_offset = 0x11000,
+   .regmap_cfg = _snoc_regmap_config,
 };
 
 
-- 
2.45.1




[PATCH 5/7] interconnect: qcom: qcs404: Introduce AP-owned nodes

2024-06-09 Thread Adam Skladowski
When driver was first sent it seems ap_owned nodes were not available,
bring them now.

Signed-off-by: Adam Skladowski 
---
 drivers/interconnect/qcom/qcs404.c | 85 ++
 1 file changed, 85 insertions(+)

diff --git a/drivers/interconnect/qcom/qcs404.c 
b/drivers/interconnect/qcom/qcs404.c
index 11b49a89c03d..91b2ccc56a33 100644
--- a/drivers/interconnect/qcom/qcs404.c
+++ b/drivers/interconnect/qcom/qcs404.c
@@ -101,6 +101,11 @@ static struct qcom_icc_node mas_apps_proc = {
.buswidth = 8,
.mas_rpm_id = 0,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 0,
+   .qos.prio_level = 0,
+   .qos.qos_port = 0,
.num_links = ARRAY_SIZE(mas_apps_proc_links),
.links = mas_apps_proc_links,
 };
@@ -116,6 +121,11 @@ static struct qcom_icc_node mas_oxili = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 0,
+   .qos.prio_level = 0,
+   .qos.qos_port = 2,
.num_links = ARRAY_SIZE(mas_oxili_links),
.links = mas_oxili_links,
 };
@@ -131,6 +141,11 @@ static struct qcom_icc_node mas_mdp = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 0,
+   .qos.prio_level = 1,
+   .qos.qos_port = 4,
.num_links = ARRAY_SIZE(mas_mdp_links),
.links = mas_mdp_links,
 };
@@ -145,6 +160,10 @@ static struct qcom_icc_node mas_snoc_bimc_1 = {
.buswidth = 8,
.mas_rpm_id = 76,
.slv_rpm_id = -1,
+   .qos.qos_mode = NOC_QOS_MODE_BYPASS,
+   .qos.areq_prio = 0,
+   .qos.prio_level = 0,
+   .qos.qos_port = 5,
.num_links = ARRAY_SIZE(mas_snoc_bimc_1_links),
.links = mas_snoc_bimc_1_links,
 };
@@ -160,6 +179,11 @@ static struct qcom_icc_node mas_tcu_0 = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 0,
+   .qos.prio_level = 2,
+   .qos.qos_port = 6,
.num_links = ARRAY_SIZE(mas_tcu_0_links),
.links = mas_tcu_0_links,
 };
@@ -174,6 +198,8 @@ static struct qcom_icc_node mas_spdm = {
.buswidth = 4,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_INVALID,
.num_links = ARRAY_SIZE(mas_spdm_links),
.links = mas_spdm_links,
 };
@@ -231,6 +257,11 @@ static struct qcom_icc_node mas_crypto = {
.buswidth = 8,
.mas_rpm_id = 23,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 0,
.num_links = ARRAY_SIZE(mas_crypto_links),
.links = mas_crypto_links,
 };
@@ -287,6 +318,11 @@ static struct qcom_icc_node mas_qpic = {
.buswidth = 4,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 14,
.num_links = ARRAY_SIZE(mas_qpic_links),
.links = mas_qpic_links,
 };
@@ -301,6 +337,11 @@ static struct qcom_icc_node mas_qdss_bam = {
.buswidth = 4,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 1,
.num_links = ARRAY_SIZE(mas_qdss_bam_links),
.links = mas_qdss_bam_links,
 };
@@ -348,6 +389,11 @@ static struct qcom_icc_node mas_qdss_etr = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 0,
.num_links = ARRAY_SIZE(mas_qdss_etr_links),
.links = mas_qdss_etr_links,
 };
@@ -363,6 +409,11 @@ static struct qcom_icc_node mas_emac = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 17,
.num_links = ARRAY_SIZE(mas_emac_links),
.links = mas_emac_links,
 };
@@ -378,6 +429,11 @@ static struct qcom_icc_node mas_pcie = {
.buswidth = 8,
.mas_rpm_id = -1,
.slv_rpm_id = -1,
+   .qos.ap_owned = true,
+   .qos.qos_mode = NOC_QOS_MODE_FIXED,
+   .qos.areq_prio = 1,
+   .qos.prio_level = 1,
+   .qos.qos_port = 8,
.num_links = ARRAY_SIZE(mas_pcie_links),
.links = mas_pcie_links,
 };
@@ -393,6 +449,11 @@ static

[PATCH 4/7] interconnect: qcom: Add MSM8937 interconnect provider driver

2024-06-09 Thread Adam Skladowski
Add driver for interconnect busses found in MSM8937 based platforms.
The topology consists of four NoCs that are partially controlled
by a RPM processor.

Signed-off-by: Adam Skladowski 
---
 drivers/interconnect/qcom/Kconfig   |9 +
 drivers/interconnect/qcom/Makefile  |2 +
 drivers/interconnect/qcom/msm8937.c | 1374 +++
 3 files changed, 1385 insertions(+)
 create mode 100644 drivers/interconnect/qcom/msm8937.c

diff --git a/drivers/interconnect/qcom/Kconfig 
b/drivers/interconnect/qcom/Kconfig
index a0e9c09954ed..c3c534e7dad6 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -26,6 +26,15 @@ config INTERCONNECT_QCOM_MSM8916
  This is a driver for the Qualcomm Network-on-Chip on msm8916-based
  platforms.
 
+config INTERCONNECT_QCOM_MSM8937
+   tristate "Qualcomm MSM8937 interconnect driver"
+   depends on INTERCONNECT_QCOM
+   depends on QCOM_SMD_RPM
+   select INTERCONNECT_QCOM_SMD_RPM
+   help
+ This is a driver for the Qualcomm Network-on-Chip on msm8937-based
+ platforms.
+
 config INTERCONNECT_QCOM_MSM8939
tristate "Qualcomm MSM8939 interconnect driver"
depends on INTERCONNECT_QCOM
diff --git a/drivers/interconnect/qcom/Makefile 
b/drivers/interconnect/qcom/Makefile
index 21ce45438258..a27dcb474df5 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -6,6 +6,7 @@ interconnect_qcom-y := icc-common.o
 icc-bcm-voter-objs := bcm-voter.o
 qnoc-msm8909-objs  := msm8909.o
 qnoc-msm8916-objs  := msm8916.o
+qnoc-msm8937-objs  := msm8937.o
 qnoc-msm8939-objs  := msm8939.o
 qnoc-msm8974-objs  := msm8974.o
 qnoc-msm8976-objs  := msm8976.o
@@ -41,6 +42,7 @@ icc-smd-rpm-objs  := smd-rpm.o icc-rpm.o 
icc-rpm-clocks.o
 obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8909) += qnoc-msm8909.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += qnoc-msm8916.o
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8937) += qnoc-msm8937.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8939) += qnoc-msm8939.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8974) += qnoc-msm8974.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8976) += qnoc-msm8976.o
diff --git a/drivers/interconnect/qcom/msm8937.c 
b/drivers/interconnect/qcom/msm8937.c
new file mode 100644
index ..470175c1c38b
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8937.c
@@ -0,0 +1,1374 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Based on data from msm8937-bus.dtsi in Qualcomm's msm-3.18 release:
+ *   Copyright (c) 2014-2016, The Linux Foundation. All rights reserved.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include 
+
+#include "icc-rpm.h"
+
+enum {
+   QNOC_MASTER_AMPSS_M0 = 1,
+   QNOC_MASTER_GRAPHICS_3D,
+   QNOC_SNOC_BIMC_0_MAS,
+   QNOC_SNOC_BIMC_2_MAS,
+   QNOC_SNOC_BIMC_1_MAS,
+   QNOC_MASTER_TCU_0,
+   QNOC_MASTER_SPDM,
+   QNOC_MASTER_BLSP_1,
+   QNOC_MASTER_BLSP_2,
+   QNOC_MASTER_USB_HS,
+   QNOC_MASTER_XM_USB_HS1,
+   QNOC_MASTER_CRYPTO_CORE0,
+   QNOC_MASTER_SDCC_1,
+   QNOC_MASTER_SDCC_2,
+   QNOC_SNOC_PNOC_MAS,
+   QNOC_MASTER_QDSS_BAM,
+   QNOC_BIMC_SNOC_MAS,
+   QNOC_MASTER_JPEG,
+   QNOC_MASTER_MDP_PORT0,
+   QNOC_PNOC_SNOC_MAS,
+   QNOC_MASTER_VIDEO_P0,
+   QNOC_MASTER_VFE,
+   QNOC_MASTER_VFE1,
+   QNOC_MASTER_CPP,
+   QNOC_MASTER_QDSS_ETR,
+   QNOC_PNOC_M_0,
+   QNOC_PNOC_M_1,
+   QNOC_PNOC_INT_0,
+   QNOC_PNOC_INT_1,
+   QNOC_PNOC_INT_2,
+   QNOC_PNOC_INT_3,
+   QNOC_PNOC_SLV_0,
+   QNOC_PNOC_SLV_1,
+   QNOC_PNOC_SLV_2,
+   QNOC_PNOC_SLV_3,
+   QNOC_PNOC_SLV_4,
+   QNOC_PNOC_SLV_6,
+   QNOC_PNOC_SLV_7,
+   QNOC_PNOC_SLV_8,
+   QNOC_SNOC_QDSS_INT,
+   QNOC_SNOC_INT_0,
+   QNOC_SNOC_INT_1,
+   QNOC_SNOC_INT_2,
+   QNOC_SLAVE_EBI_CH0,
+   QNOC_BIMC_SNOC_SLV,
+   QNOC_SLAVE_SDCC_2,
+   QNOC_SLAVE_SPDM_WRAPPER,
+   QNOC_SLAVE_PDM,
+   QNOC_SLAVE_PRNG,
+   QNOC_SLAVE_TCSR,
+   QNOC_SLAVE_SNOC_CFG,
+   QNOC_SLAVE_MESSAGE_RAM,
+   QNOC_SLAVE_CAMERA_CFG,
+   QNOC_SLAVE_DISPLAY_CFG,
+   QNOC_SLAVE_VENUS_CFG,
+   QNOC_SLAVE_GRAPHICS_3D_CFG,
+   QNOC_SLAVE_TLMM,
+   QNOC_SLAVE_BLSP_1,
+   QNOC_SLAVE_BLSP_2,
+   QNOC_SLAVE_PMIC_ARB,
+   QNOC_SLAVE_SDCC_1,
+   QNOC_SLAVE_CRYPTO_0_CFG,
+   QNOC_SLAVE_USB_HS,
+   QNOC_SLAVE_TCU,
+   QNOC_PNOC_SNOC_SLV,
+   QNOC_SLAVE_APPSS,
+   QNOC_SLAVE_WCSS,
+   QNOC_SNOC_BIMC_0_SLV,
+   QNOC_SNOC_BIMC_1_SLV,
+   QNOC_SNOC_BIMC_2_SLV,
+   QNOC_SLAVE_OCIMEM,
+   QNOC_SNOC_PNOC_SLV,
+   QNOC_SLAVE_QDSS_ST

[PATCH 3/7] dt-bindings: interconnect: Add Qualcomm MSM8937 DT bindings

2024-06-09 Thread Adam Skladowski
Add bindings for Qualcomm MSM8937 Network-On-Chip interconnect devices.

Signed-off-by: Adam Skladowski 
---
 .../bindings/interconnect/qcom,msm8937.yaml   | 81 
 .../dt-bindings/interconnect/qcom,msm8937.h   | 93 +++
 2 files changed, 174 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,msm8937.yaml
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8937.h

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8937.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,msm8937.yaml
new file mode 100644
index ..39a1ca441bb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8937.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,msm8937.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8937 Network-On-Chip interconnect
+
+maintainers:
+  - Konrad Dybcio 
+
+description: |
+  The Qualcomm MSM8937 interconnect providers support adjusting the
+  bandwidth requirements between the various NoC fabrics.
+
+allOf:
+  - $ref: qcom,rpm-common.yaml#
+
+properties:
+  compatible:
+enum:
+  - qcom,msm8937-bimc
+  - qcom,msm8937-pcnoc
+  - qcom,msm8937-snoc
+
+  reg:
+maxItems: 1
+
+patternProperties:
+  '^interconnect-[a-z0-9\-]+$':
+type: object
+$ref: qcom,rpm-common.yaml#
+description:
+  The interconnect providers do not have a separate QoS register space,
+  but share parent's space.
+
+allOf:
+  - $ref: qcom,rpm-common.yaml#
+
+properties:
+  compatible:
+const: qcom,msm8937-snoc-mm
+
+required:
+  - compatible
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+bimc: interconnect@40 {
+compatible = "qcom,msm8937-bimc";
+reg = <0x0040 0x5a000>;
+#interconnect-cells = <2>;
+};
+
+pcnoc: interconnect@50 {
+compatible = "qcom,msm8937-pcnoc";
+reg = <0x0050 0x13080>;
+#interconnect-cells = <2>;
+};
+
+snoc: interconnect@58 {
+compatible = "qcom,msm8937-bimc";
+reg = <0x0058 0x16080>;
+#interconnect-cells = <2>;
+
+  snoc_mm: interconnect-snoc {
+  compatible = "qcom,msm8937-snoc-mm";
+  #interconnect-cells = <2>;
+  };
+};
diff --git a/include/dt-bindings/interconnect/qcom,msm8937.h 
b/include/dt-bindings/interconnect/qcom,msm8937.h
new file mode 100644
index ..98b8a4637aab
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,msm8937.h
@@ -0,0 +1,93 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Qualcomm MSM8937 interconnect IDs
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_MSM8937_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_MSM8937_H
+
+/* BIMC fabric */
+#define MAS_APPS_PROC  0
+#define MAS_OXILI  1
+#define MAS_SNOC_BIMC_02
+#define MAS_SNOC_BIMC_23
+#define MAS_SNOC_BIMC_14
+#define MAS_TCU_0  5
+#define SLV_EBI6
+#define SLV_BIMC_SNOC  7
+
+/* PCNOC fabric */
+#define MAS_SPDM   0
+#define MAS_BLSP_1 1
+#define MAS_BLSP_2 2
+#define MAS_USB_HS13
+#define MAS_XI_USB_HS1 4
+#define MAS_CRYPTO 5
+#define MAS_SDCC_1 6
+#define MAS_SDCC_2 7
+#define MAS_SNOC_PCNOC 8
+#define PCNOC_M_0  9
+#define PCNOC_M_1  10
+#define PCNOC_INT_011
+#define PCNOC_INT_112
+#define PCNOC_INT_213
+#define PCNOC_INT_314
+#define PCNOC_S_0  15
+#define PCNOC_S_1  16
+#define PCNOC_S_2  17
+#define PCNOC_S_3  18
+#define PCNOC_S_4  19
+#define PCNOC_S_6  20
+#define PCNOC_S_7  21
+#define PCNOC_S_8  22
+#define SLV_SDCC_2 23
+#define SLV_SPDM   24
+#define SLV_PDM25
+#define SLV_PRNG   26
+#define SLV_TCSR   27
+#define SLV_SNOC_CFG   28
+#define SLV_MESSAGE_RAM29
+#define SLV_CAMERA_SS_CFG  30
+#define SLV_DISP_SS_CFG31
+#define SLV_VENUS_CFG  32
+#define SLV_GPU_CFG33
+#define SLV_TLMM   34
+#define SLV_BLSP_1 35
+#define SLV_BLSP_2 36
+#define SLV_PMIC_ARB   37
+#define SLV_SDCC_1 38
+#define SLV_CRYPTO_0_CFG   39
+#define SLV_USB_HS 40
+#define SLV_TCU41
+#define SLV_PCNOC_SNOC 42
+
+/* SNOC fabr

[PATCH 2/7] interconnect: qcom: Add MSM8976 interconnect provider driver

2024-06-09 Thread Adam Skladowski
Add driver for interconnect busses found in MSM8976 based platforms.
The topology consists of four NoCs that are partially controlled
by a RPM processor.

Signed-off-by: Adam Skladowski 
---
 drivers/interconnect/qcom/Kconfig   |9 +
 drivers/interconnect/qcom/Makefile  |2 +
 drivers/interconnect/qcom/msm8976.c | 1443 +++
 3 files changed, 1454 insertions(+)
 create mode 100644 drivers/interconnect/qcom/msm8976.c

diff --git a/drivers/interconnect/qcom/Kconfig 
b/drivers/interconnect/qcom/Kconfig
index 1446a839184e..a0e9c09954ed 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -44,6 +44,15 @@ config INTERCONNECT_QCOM_MSM8974
 This is a driver for the Qualcomm Network-on-Chip on msm8974-based
 platforms.
 
+config INTERCONNECT_QCOM_MSM8976
+   tristate "Qualcomm MSM8976 interconnect driver"
+   depends on INTERCONNECT_QCOM
+   depends on QCOM_SMD_RPM
+   select INTERCONNECT_QCOM_SMD_RPM
+   help
+This is a driver for the Qualcomm Network-on-Chip on msm8976-based
+platforms.
+
 config INTERCONNECT_QCOM_MSM8996
tristate "Qualcomm MSM8996 interconnect driver"
depends on INTERCONNECT_QCOM
diff --git a/drivers/interconnect/qcom/Makefile 
b/drivers/interconnect/qcom/Makefile
index 2ea3113d0a4d..21ce45438258 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -8,6 +8,7 @@ qnoc-msm8909-objs   := msm8909.o
 qnoc-msm8916-objs  := msm8916.o
 qnoc-msm8939-objs  := msm8939.o
 qnoc-msm8974-objs  := msm8974.o
+qnoc-msm8976-objs  := msm8976.o
 qnoc-msm8996-objs  := msm8996.o
 icc-osm-l3-objs:= osm-l3.o
 qnoc-qcm2290-objs  := qcm2290.o
@@ -42,6 +43,7 @@ obj-$(CONFIG_INTERCONNECT_QCOM_MSM8909) += qnoc-msm8909.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += qnoc-msm8916.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8939) += qnoc-msm8939.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8974) += qnoc-msm8974.o
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8976) += qnoc-msm8976.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8996) += qnoc-msm8996.o
 obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o
 obj-$(CONFIG_INTERCONNECT_QCOM_QCM2290) += qnoc-qcm2290.o
diff --git a/drivers/interconnect/qcom/msm8976.c 
b/drivers/interconnect/qcom/msm8976.c
new file mode 100644
index ..b6cefdf0fecb
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8976.c
@@ -0,0 +1,1443 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Based on data from msm8976-bus.dtsi in Qualcomm's msm-3.10 release:
+ *   Copyright (c) 2014-2016, The Linux Foundation. All rights reserved.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include 
+
+#include "icc-rpm.h"
+
+static const char * const snoc_intf_clocks[] = {
+   "ipa", /* mas_ipa */
+};
+
+enum {
+   QNOC_MASTER_AMPSS_M0 = 1,
+   QNOC_MNOC_BIMC_MAS,
+   QNOC_SNOC_BIMC_MAS,
+   QNOC_MASTER_TCU_0,
+   QNOC_MASTER_USB_HS2,
+   QNOC_MASTER_BLSP_1,
+   QNOC_MASTER_USB_HS,
+   QNOC_MASTER_BLSP_2,
+   QNOC_MASTER_CRYPTO_CORE0,
+   QNOC_MASTER_SDCC_1,
+   QNOC_MASTER_SDCC_2,
+   QNOC_MASTER_SDCC_3,
+   QNOC_SNOC_PNOC_MAS,
+   QNOC_MASTER_LPASS_AHB,
+   QNOC_MASTER_SPDM,
+   QNOC_MASTER_DEHR,
+   QNOC_MASTER_XM_USB_HS1,
+   QNOC_MASTER_QDSS_BAM,
+   QNOC_BIMC_SNOC_MAS,
+   QNOC_MASTER_JPEG,
+   QNOC_MASTER_GRAPHICS_3D,
+   QNOC_MASTER_MDP_PORT0,
+   QNOC_MASTER_MDP_PORT1,
+   QNOC_PNOC_SNOC_MAS,
+   QNOC_MASTER_VIDEO_P0,
+   QNOC_MASTER_VIDEO_P1,
+   QNOC_MASTER_VFE0,
+   QNOC_MASTER_VFE1,
+   QNOC_MASTER_CPP,
+   QNOC_MASTER_QDSS_ETR,
+   QNOC_MASTER_LPASS_PROC,
+   QNOC_MASTER_IPA,
+   QNOC_PNOC_M_0,
+   QNOC_PNOC_M_1,
+   QNOC_PNOC_INT_0,
+   QNOC_PNOC_INT_1,
+   QNOC_PNOC_INT_2,
+   QNOC_PNOC_SLV_1,
+   QNOC_PNOC_SLV_2,
+   QNOC_PNOC_SLV_3,
+   QNOC_PNOC_SLV_4,
+   QNOC_PNOC_SLV_8,
+   QNOC_PNOC_SLV_9,
+   QNOC_SNOC_MM_INT_0,
+   QNOC_SNOC_QDSS_INT,
+   QNOC_SNOC_INT_0,
+   QNOC_SNOC_INT_1,
+   QNOC_SNOC_INT_2,
+   QNOC_SLAVE_EBI_CH0,
+   QNOC_BIMC_SNOC_SLV,
+   QNOC_SLAVE_TCSR,
+   QNOC_SLAVE_TLMM,
+   QNOC_SLAVE_CRYPTO_0_CFG,
+   QNOC_SLAVE_MESSAGE_RAM,
+   QNOC_SLAVE_PDM,
+   QNOC_SLAVE_PRNG,
+   QNOC_SLAVE_PMIC_ARB,
+   QNOC_SLAVE_SNOC_CFG,
+   QNOC_SLAVE_DCC_CFG,
+   QNOC_SLAVE_CAMERA_CFG,
+   QNOC_SLAVE_DISPLAY_CFG,
+   QNOC_SLAVE_VENUS_CFG,
+   QNOC_SLAVE_SDCC_1,
+   QNOC_SLAVE_BLSP_1,
+   QNOC_SLAVE_USB_HS,
+   QNOC_SLAVE_SDCC_3,
+   QNOC_SLAVE_SDCC_2,
+   QNOC_SLAVE_GRAPHICS_3D_CFG,
+   QNOC_SLAVE_USB_HS2,
+   QNOC_

[PATCH 1/7] dt-bindings: interconnect: Add Qualcomm MSM8976 DT bindings

2024-06-09 Thread Adam Skladowski
Add bindings for Qualcomm MSM8976 Network-On-Chip interconnect devices.

Signed-off-by: Adam Skladowski 
---
 .../bindings/interconnect/qcom,msm8976.yaml   | 107 ++
 .../dt-bindings/interconnect/qcom,msm8976.h   |  97 
 2 files changed, 204 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,msm8976.yaml
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8976.h

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8976.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,msm8976.yaml
new file mode 100644
index ..bc9d08443e7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8976.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,msm8976.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8976 Network-On-Chip interconnect
+
+maintainers:
+  - Konrad Dybcio 
+
+description: |
+  The Qualcomm MSM8976 interconnect providers support adjusting the
+  bandwidth requirements between the various NoC fabrics.
+
+properties:
+  compatible:
+enum:
+  - qcom,msm8976-bimc
+  - qcom,msm8976-pcnoc
+  - qcom,msm8976-snoc
+
+  reg:
+maxItems: 1
+
+  clock-names:
+minItems: 1
+maxItems: 2
+
+  clocks:
+minItems: 1
+maxItems: 2
+
+patternProperties:
+  '^interconnect-[a-z0-9\-]+$':
+type: object
+$ref: qcom,rpm-common.yaml#
+description:
+  The interconnect providers do not have a separate QoS register space,
+  but share parent's space.
+
+allOf:
+  - $ref: qcom,rpm-common.yaml#
+
+properties:
+  compatible:
+const: qcom,msm8976-snoc-mm
+
+required:
+  - compatible
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+allOf:
+  - $ref: qcom,rpm-common.yaml#
+  - if:
+  properties:
+compatible:
+  const: qcom,msm8976-snoc
+
+then:
+  properties:
+clocks:
+  items:
+- description: IPA clock from RPMCC
+clock-names:
+  const: ipa
+
+  required:
+- clocks
+- clock-names
+
+examples:
+  - |
+#include 
+#include 
+
+bimc: interconnect@40 {
+compatible = "qcom,msm8976-bimc";
+reg = <0x0040 0x62000>;
+#interconnect-cells = <2>;
+};
+
+pcnoc: interconnect@50 {
+compatible = "qcom,msm8976-pcnoc";
+reg = <0x0050 0x14000>;
+#interconnect-cells = <2>;
+};
+
+snoc: interconnect@58 {
+compatible = "qcom,msm8976-snoc";
+reg = <0x0058 0x1a000>;
+clocks =  < RPM_SMD_IPA_CLK>;
+clock-names = "ipa";
+#interconnect-cells = <2>;
+
+  snoc_mm: interconnect-snoc {
+  compatible = "qcom,msm8976-snoc-mm";
+  #interconnect-cells = <2>;
+  };
+};
diff --git a/include/dt-bindings/interconnect/qcom,msm8976.h 
b/include/dt-bindings/interconnect/qcom,msm8976.h
new file mode 100644
index ..4ea90f22320e
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,msm8976.h
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Qualcomm MSM8976 interconnect IDs
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_MSM8976_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_MSM8976_H
+
+/* BIMC fabric */
+#define MAS_APPS_PROC  0
+#define MAS_SMMNOC_BIMC1
+#define MAS_SNOC_BIMC  2
+#define MAS_TCU_0  3
+#define SLV_EBI4
+#define SLV_BIMC_SNOC  5
+
+/* PCNOC fabric */
+#define MAS_USB_HS20
+#define MAS_BLSP_1 1
+#define MAS_USB_HS12
+#define MAS_BLSP_2 3
+#define MAS_CRYPTO 4
+#define MAS_SDCC_1 5
+#define MAS_SDCC_2 6
+#define MAS_SDCC_3 7
+#define MAS_SNOC_PCNOC 8
+#define MAS_LPASS_AHB  9
+#define MAS_SPDM   10
+#define MAS_DEHR   11
+#define MAS_XM_USB_HS1 12
+#define PCNOC_M_0  13
+#define PCNOC_M_1  14
+#define PCNOC_INT_015
+#define PCNOC_INT_116
+#define PCNOC_INT_217
+#define PCNOC_S_1  18
+#define PCNOC_S_2  19
+#define PCNOC_S_3  20
+#define PCNOC_S_4  21
+#define PCNOC_S_8  22
+#define PCNOC_S_9  23
+#define SLV_TCSR   24
+#define SLV_TLMM   25
+#define SLV_CRYPTO_0_CFG   26
+#define SLV_MESSAGE_RAM27
+#define SLV_PDM28
+#define SLV_PRNG   29
+#define SLV_PMIC_ARB   30
+#define SLV_SNOC_CFG   31
+#define SLV_D

[PATCH 0/7] msm8937/msm8976/qcs404 icc patches

2024-06-09 Thread Adam Skladowski
This series introduce new ICC drivers for some legacy socs
while at it also updates a bit of qcs404 driver which seems
to not receive much attention lately.
Please take in consideration i do not own any qcs404 board
so i cannot test anything else than if it compiles.

Adam Skladowski (7):
  dt-bindings: interconnect: Add Qualcomm MSM8976 DT bindings
  interconnect: qcom: Add MSM8976 interconnect provider driver
  dt-bindings: interconnect: Add Qualcomm MSM8937 DT bindings
  interconnect: qcom: Add MSM8937 interconnect provider driver
  interconnect: qcom: qcs404: Introduce AP-owned nodes
  interconnect: qcom: qcs404: Add regmaps and more bus descriptions
  dt-bindings: interconnect: qcom: msm8939: Fix example

 .../bindings/interconnect/qcom,msm8937.yaml   |   81 +
 .../bindings/interconnect/qcom,msm8939.yaml   |   22 +-
 .../bindings/interconnect/qcom,msm8976.yaml   |  107 ++
 drivers/interconnect/qcom/Kconfig |   18 +
 drivers/interconnect/qcom/Makefile|4 +
 drivers/interconnect/qcom/msm8937.c   | 1374 
 drivers/interconnect/qcom/msm8976.c   | 1443 +
 drivers/interconnect/qcom/qcs404.c|  126 +-
 .../dt-bindings/interconnect/qcom,msm8937.h   |   93 ++
 .../dt-bindings/interconnect/qcom,msm8976.h   |   97 ++
 10 files changed, 3354 insertions(+), 11 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,msm8937.yaml
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,msm8976.yaml
 create mode 100644 drivers/interconnect/qcom/msm8937.c
 create mode 100644 drivers/interconnect/qcom/msm8976.c
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8937.h
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8976.h

-- 
2.45.1




[PATCH v4 4/4] arm64: dts: qcom: msm8976: Add WCNSS node

2024-05-08 Thread Adam Skladowski
Add node describing wireless connectivity subsystem.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 22a6a09a904d..a7f772485bf5 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -771,6 +771,36 @@ blsp2_i2c4_sleep: blsp2-i2c4-sleep-state {
drive-strength = <2>;
bias-disable;
};
+
+   wcss_wlan_default: wcss-wlan-default-state  {
+   wcss-wlan2-pins {
+   pins = "gpio40";
+   function = "wcss_wlan2";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan1-pins {
+   pins = "gpio41";
+   function = "wcss_wlan1";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan0-pins {
+   pins = "gpio42";
+   function = "wcss_wlan0";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan-pins {
+   pins = "gpio43", "gpio44";
+   function = "wcss_wlan";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+   };
};
 
gcc: clock-controller@180 {
@@ -1458,6 +1488,81 @@ blsp2_i2c4: i2c@7af8000 {
status = "disabled";
};
 
+   wcnss: remoteproc@a204000 {
+   compatible = "qcom,pronto-v3-pil", "qcom,pronto";
+   reg = <0x0a204000 0x2000>,
+ <0x0a202000 0x1000>,
+ <0x0a21b000 0x3000>;
+   reg-names = "ccu",
+   "dxe",
+   "pmu";
+
+   memory-region = <_fw_mem>;
+
+   interrupts-extended = < GIC_SPI 149 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 
IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+   power-domains = < MSM8976_VDDCX>,
+   < MSM8976_VDDMX>;
+   power-domain-names = "cx", "mx";
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   pinctrl-0 = <_wlan_default>;
+   pinctrl-names = "default";
+
+   status = "disabled";
+
+   wcnss_iris: iris {
+   /* Separate chip, compatible is board-specific 
*/
+   clocks = < RPM_SMD_RF_CLK2>;
+   clock-names = "xo";
+   };
+
+   smd-edge {
+   interrupts = ;
+
+   mboxes = < 17>;
+   qcom,smd-edge = <6>;
+   qcom,remote-pid = <4>;
+
+   label = "pronto";
+
+   wcnss_ctrl: wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   

[PATCH v4 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU

2024-05-08 Thread Adam Skladowski
Add Adreno GPU node.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 71 +++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index b26c35796928..22a6a09a904d 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -1080,6 +1080,77 @@ mdss_dsi1_phy: phy@1a96a00 {
};
};
 
+   adreno_gpu: gpu@1c0 {
+   compatible = "qcom,adreno-510.0", "qcom,adreno";
+
+   reg = <0x01c0 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   clocks = < GCC_GFX3D_OXILI_CLK>,
+< GCC_GFX3D_OXILI_AHB_CLK>,
+< GCC_GFX3D_OXILI_GMEM_CLK>,
+< GCC_GFX3D_BIMC_CLK>,
+< GCC_GFX3D_OXILI_TIMER_CLK>,
+< GCC_GFX3D_OXILI_AON_CLK>;
+   clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer",
+ "alwayson";
+
+   power-domains = < OXILI_GX_GDSC>;
+
+   iommus = <_iommu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   status = "disabled";
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = <_opp_low_svs>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = <_opp_svs>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   required-opps = <_opp_nom>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-48000 {
+   opp-hz = /bits/ 64 <48000>;
+   required-opps = <_opp_nom_plus>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = <_opp_turbo>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   required-opps = <_opp_turbo>;
+   opp-supported-hw = <0xff>;
+   };
+   };
+   };
+
apps_iommu: iommu@1ee {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee 0x3000>;
-- 
2.44.0




[PATCH v4 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes

2024-05-08 Thread Adam Skladowski
Add MDSS nodes to support displays on MSM8976 SoC.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 280 +-
 1 file changed, 276 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 8bdcc1438177..b26c35796928 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -785,10 +785,10 @@ gcc: clock-controller@180 {
 
clocks = < RPM_SMD_XO_CLK_SRC>,
 < RPM_SMD_XO_A_CLK_SRC>,
-<0>,
-<0>,
-<0>,
-<0>;
+<_dsi0_phy 1>,
+<_dsi0_phy 0>,
+<_dsi1_phy 1>,
+<_dsi1_phy 0>;
clock-names = "xo",
  "xo_a",
  "dsi0pll",
@@ -808,6 +808,278 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   mdss: display-subsystem@1a0 {
+   compatible = "qcom,mdss";
+
+   reg = <0x01a0 0x1000>,
+ <0x01ab 0x3000>;
+   reg-names = "mdss_phys", "vbif_phys";
+
+   power-domains = < MDSS_GDSC>;
+   interrupts = ;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDSS_MDP_CLK>;
+   clock-names = "iface",
+ "bus",
+ "vsync",
+ "core";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   status = "disabled";
+
+   mdss_mdp: display-controller@1a01000 {
+   compatible = "qcom,msm8976-mdp5", "qcom,mdp5";
+   reg = <0x01a01000 0x89000>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <>;
+   interrupts = <0>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDP_TBU_CLK>,
+< GCC_MDP_RT_TBU_CLK>;
+   clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "tbu",
+ "tbu_rt";
+
+   operating-points-v2 = <_opp_table>;
+   power-domains = < MDSS_GDSC>;
+
+   iommus = <_iommu 22>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mdss_mdp5_intf1_out: endpoint {
+   remote-endpoint = 
<_dsi0_in>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mdss_mdp5_intf2_out: endpoint {
+   remote-endpoint = 
<_dsi1_in>;
+   };
+   };
+   };
+
+   mdp_opp_table: opp-table {
+  

[PATCH v4 1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes

2024-05-08 Thread Adam Skladowski
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..8bdcc1438177 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -808,6 +808,87 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   apps_iommu: iommu@1ee {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   reg = <0x01ee 0x3000>;
+   ranges  = <0 0x01e2 0x2>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_APSS_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   qcom,iommu-secure-id = <17>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* VFE */
+   iommu-ctx@15000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x15000 0x1000>;
+   qcom,ctx-asid = <20>;
+   interrupts = ;
+   };
+
+   /* VENUS NS */
+   iommu-ctx@16000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x16000 0x1000>;
+   qcom,ctx-asid = <21>;
+   interrupts = ;
+   };
+
+   /* MDP0 */
+   iommu-ctx@17000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x17000 0x1000>;
+   qcom,ctx-asid = <22>;
+   interrupts = ;
+   };
+   };
+
+   gpu_iommu: iommu@1f08000 {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   ranges = <0 0x01f08000 0x8000>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_GFX3D_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   power-domains = < OXILI_CX_GDSC>;
+
+   qcom,iommu-secure-id = <18>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* gfx3d user */
+   iommu-ctx@0 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x0 0x1000>;
+   qcom,ctx-asid = <0>;
+   interrupts = ;
+   };
+
+   /* gfx3d secure */
+   iommu-ctx@1000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x1000 0x1000>;
+   qcom,ctx-asid = <2>;
+   interrupts = ;
+   };
+
+   /* gfx3d priv */
+   iommu-ctx@2000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x2000 0x1000>;
+   qcom,ctx-asid = <1>;
+   interrupts = ;
+   };
+   };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x1000>,
-- 
2.44.0




[PATCH v4 0/4] MSM8976 MDSS/GPU/WCNSS support

2024-05-08 Thread Adam Skladowski
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.

Changes since v3

1. Minor styling fixes
2. Converted qcom,ipc into mailbox on wcnss patch

Changes since v2

1. Disabled mdss_dsi nodes by default
2. Changed reg size of mdss_dsi0 to be equal on both
3. Added operating points to second mdss_dsi
4. Brought back required opp-supported-hw on adreno
5. Moved status under operating points on adreno

Changes since v1

1. Addressed feedback
2. Dropped already applied dt-bindings patches
3. Dropped sdc patch as it was submitted as part of other series
4. Dropped dt-bindings patch for Adreno, also separate now

Adam Skladowski (4):
  arm64: dts: qcom: msm8976: Add IOMMU nodes
  arm64: dts: qcom: msm8976: Add MDSS nodes
  arm64: dts: qcom: msm8976: Add Adreno GPU
  arm64: dts: qcom: msm8976: Add WCNSS node

 arch/arm64/boot/dts/qcom/msm8976.dtsi | 537 +-
 1 file changed, 533 insertions(+), 4 deletions(-)

-- 
2.44.0




[PATCH next] vhost_task: after freeing vhost_task it should not be accessed in vhost_task_fn

2024-04-30 Thread Edward Adam Davis
[syzbot reported]
BUG: KASAN: slab-use-after-free in instrument_atomic_read 
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in atomic_long_read 
include/linux/atomic/atomic-instrumented.h:3188 [inline]
BUG: KASAN: slab-use-after-free in __mutex_unlock_slowpath+0xef/0x750 
kernel/locking/mutex.c:921
Read of size 8 at addr 888023632880 by task vhost-5104/5105

CPU: 0 PID: 5105 Comm: vhost-5104 Not tainted 6.9.0-rc5-next-20240426-syzkaller 
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
03/27/2024
Call Trace:
 
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 instrument_atomic_read include/linux/instrumented.h:68 [inline]
 atomic_long_read include/linux/atomic/atomic-instrumented.h:3188 [inline]
 __mutex_unlock_slowpath+0xef/0x750 kernel/locking/mutex.c:921
 vhost_task_fn+0x3bc/0x3f0 kernel/vhost_task.c:65
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 

Allocated by task 5104:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
 kasan_kmalloc include/linux/kasan.h:211 [inline]
 kmalloc_trace_noprof+0x19c/0x2b0 mm/slub.c:4146
 kmalloc_noprof include/linux/slab.h:660 [inline]
 kzalloc_noprof include/linux/slab.h:778 [inline]
 vhost_task_create+0x149/0x300 kernel/vhost_task.c:134
 vhost_worker_create+0x17b/0x3f0 drivers/vhost/vhost.c:667
 vhost_dev_set_owner+0x563/0x940 drivers/vhost/vhost.c:945
 vhost_dev_ioctl+0xda/0xda0 drivers/vhost/vhost.c:2108
 vhost_vsock_dev_ioctl+0x2bb/0xfa0 drivers/vhost/vsock.c:875
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5104:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2190 [inline]
 slab_free mm/slub.c:4430 [inline]
 kfree+0x149/0x350 mm/slub.c:4551
 vhost_worker_destroy drivers/vhost/vhost.c:629 [inline]
 vhost_workers_free drivers/vhost/vhost.c:648 [inline]
 vhost_dev_cleanup+0x9b0/0xba0 drivers/vhost/vhost.c:1051
 vhost_vsock_dev_release+0x3aa/0x410 drivers/vhost/vsock.c:751
 __fput+0x406/0x8b0 fs/file_table.c:422
 __do_sys_close fs/open.c:1555 [inline]
 __se_sys_close fs/open.c:1540 [inline]
 __x64_sys_close+0x7f/0x110 fs/open.c:1540
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Fix]
Delete the member exit_mutex from the struct vhost_task and replace it with a
declared global static mutex.

Fixes: a3df30984f4f ("vhost_task: Handle SIGKILL by flushing work and exiting")
Reported--by: syzbot+98edc2df894917b34...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis 
---
 kernel/vhost_task.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/vhost_task.c b/kernel/vhost_task.c
index 48c289947b99..375356499867 100644
--- a/kernel/vhost_task.c
+++ b/kernel/vhost_task.c
@@ -20,10 +20,10 @@ struct vhost_task {
struct completion exited;
unsigned long flags;
struct task_struct *task;
-   /* serialize SIGKILL and vhost_task_stop calls */
-   struct mutex exit_mutex;
 };
 
+static DEFINE_MUTEX(exit_mutex); //serialize SIGKILL and vhost_task_stop calls
+
 static int vhost_task_fn(void *data)
 {
struct vhost_task *vtsk = data;
@@ -51,7 +51,7 @@ static int vhost_task_fn(void *data)
schedule();
}
 
-   mutex_lock(>exit_mutex);
+   mutex_lock(_mutex);
/*
 * If a vhost_task_stop and SIGKILL race, we can ignore the SIGKILL.
 * When the vhost layer has called vhost_task_stop it's already stopped
@@ -62,7 +62,7 @@ static int vhost_task_fn(void *data)
vtsk->handle_sigkill(vtsk->data);
}
complete(>exited);
-   mutex_unlock(>exit_mutex);
+   mutex_unlock(_mutex);
 
do_exit(0);
 }
@@ -88,12 +88,12 @@ EXPORT_SYMBOL_GPL(vhost_task_wake);
  */
 void vhost_task_stop(struct vhost_task *vtsk)
 {
-   mutex_lock(>exit_mutex);
+   mutex_lock(_mutex);
if (!test_bit(VHOST_TASK_FLAGS_KILLED, >flags)) {
set_bi

[PATCH v3 4/4] arm64: dts: qcom: msm8976: Add WCNSS node

2024-04-13 Thread Adam Skladowski
Add node describing wireless connectivity subsystem.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 104 ++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index acb6331999bd..1e492bcc56f0 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -771,6 +771,36 @@ blsp2_i2c4_sleep: blsp2-i2c4-sleep-state {
drive-strength = <2>;
bias-disable;
};
+
+   wcss_wlan_default: wcss-wlan-default-state  {
+   wcss-wlan2-pins {
+   pins = "gpio40";
+   function = "wcss_wlan2";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan1-pins {
+   pins = "gpio41";
+   function = "wcss_wlan1";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan0-pins {
+   pins = "gpio42";
+   function = "wcss_wlan0";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan-pins {
+   pins = "gpio43", "gpio44";
+   function = "wcss_wlan";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+   };
};
 
gcc: clock-controller@180 {
@@ -1458,6 +1488,80 @@ blsp2_i2c4: i2c@7af8000 {
status = "disabled";
};
 
+   wcnss: remoteproc@a204000 {
+   compatible = "qcom,pronto-v3-pil", "qcom,pronto";
+   reg = <0x0a204000 0x2000>,
+ <0x0a202000 0x1000>,
+ <0x0a21b000 0x3000>;
+   reg-names = "ccu",
+   "dxe",
+   "pmu";
+
+   memory-region = <_fw_mem>;
+
+   interrupts-extended = < GIC_SPI 149 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 
IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+   power-domains = < MSM8976_VDDCX>,
+   < MSM8976_VDDMX>;
+   power-domain-names = "cx", "mx";
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   pinctrl-0 = <_wlan_default>;
+   pinctrl-names = "default";
+
+   status = "disabled";
+
+   wcnss_iris: iris {
+   /* Separate chip, compatible is board-specific 
*/
+   clocks = < RPM_SMD_RF_CLK2>;
+   clock-names = "xo";
+   };
+
+   smd-edge {
+   interrupts = ;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+   qcom,remote-pid = <4>;
+
+   label = "pronto";
+
+   wcnss_ctrl: wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   

[PATCH v3 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU

2024-04-13 Thread Adam Skladowski
Add Adreno GPU node.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 71 +++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index ce15c6ec9f4e..acb6331999bd 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -1080,6 +1080,77 @@ mdss_dsi1_phy: phy@1a96a00 {
};
};
 
+   adreno_gpu: gpu@1c0 {
+   compatible = "qcom,adreno-510.0", "qcom,adreno";
+
+   reg = <0x01c0 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   clocks = < GCC_GFX3D_OXILI_CLK>,
+< GCC_GFX3D_OXILI_AHB_CLK>,
+< GCC_GFX3D_OXILI_GMEM_CLK>,
+< GCC_GFX3D_BIMC_CLK>,
+< GCC_GFX3D_OXILI_TIMER_CLK>,
+< GCC_GFX3D_OXILI_AON_CLK>;
+   clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer",
+ "alwayson";
+
+   power-domains = < OXILI_GX_GDSC>;
+
+   iommus = <_iommu 0>;
+
+   operating-points-v2 = <_opp_table>;
+
+   status = "disabled";
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = <_opp_low_svs>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = <_opp_svs>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   required-opps = <_opp_nom>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-48000 {
+   opp-hz = /bits/ 64 <48000>;
+   required-opps = <_opp_nom_plus>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = <_opp_turbo>;
+   opp-supported-hw = <0xff>;
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   required-opps = <_opp_turbo>;
+   opp-supported-hw = <0xff>;
+   };
+   };
+   };
+
apps_iommu: iommu@1ee {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee 0x3000>;
-- 
2.44.0




[PATCH v3 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes

2024-04-13 Thread Adam Skladowski
Add MDSS nodes to support displays on MSM8976 SoC.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 280 +-
 1 file changed, 276 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 8bdcc1438177..ce15c6ec9f4e 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -785,10 +785,10 @@ gcc: clock-controller@180 {
 
clocks = < RPM_SMD_XO_CLK_SRC>,
 < RPM_SMD_XO_A_CLK_SRC>,
-<0>,
-<0>,
-<0>,
-<0>;
+<_dsi0_phy 1>,
+<_dsi0_phy 0>,
+<_dsi1_phy 1>,
+<_dsi1_phy 0>;
clock-names = "xo",
  "xo_a",
  "dsi0pll",
@@ -808,6 +808,278 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   mdss: display-subsystem@1a0 {
+   compatible = "qcom,mdss";
+
+   reg = <0x01a0 0x1000>,
+ <0x01ab 0x3000>;
+   reg-names = "mdss_phys", "vbif_phys";
+
+   power-domains = < MDSS_GDSC>;
+   interrupts = ;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDSS_MDP_CLK>;
+   clock-names = "iface",
+ "bus",
+ "vsync",
+ "core";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   status = "disabled";
+
+   mdss_mdp: display-controller@1a01000 {
+   compatible = "qcom,msm8976-mdp5", "qcom,mdp5";
+   reg = <0x01a01000 0x89000>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <>;
+   interrupts = <0>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDP_TBU_CLK>,
+< GCC_MDP_RT_TBU_CLK>;
+   clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "tbu",
+ "tbu_rt";
+
+   operating-points-v2 = <_opp_table>;
+   power-domains = < MDSS_GDSC>;
+
+   iommus = <_iommu 22>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mdss_mdp5_intf1_out: endpoint {
+   remote-endpoint = 
<_dsi0_in>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mdss_mdp5_intf2_out: endpoint {
+   remote-endpoint = 
<_dsi1_in>;
+   };
+   };
+   };
+
+   mdp_opp_table: opp-table {
+  

[PATCH v3 1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes

2024-04-13 Thread Adam Skladowski
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..8bdcc1438177 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -808,6 +808,87 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   apps_iommu: iommu@1ee {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   reg = <0x01ee 0x3000>;
+   ranges  = <0 0x01e2 0x2>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_APSS_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   qcom,iommu-secure-id = <17>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* VFE */
+   iommu-ctx@15000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x15000 0x1000>;
+   qcom,ctx-asid = <20>;
+   interrupts = ;
+   };
+
+   /* VENUS NS */
+   iommu-ctx@16000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x16000 0x1000>;
+   qcom,ctx-asid = <21>;
+   interrupts = ;
+   };
+
+   /* MDP0 */
+   iommu-ctx@17000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x17000 0x1000>;
+   qcom,ctx-asid = <22>;
+   interrupts = ;
+   };
+   };
+
+   gpu_iommu: iommu@1f08000 {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   ranges = <0 0x01f08000 0x8000>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_GFX3D_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   power-domains = < OXILI_CX_GDSC>;
+
+   qcom,iommu-secure-id = <18>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* gfx3d user */
+   iommu-ctx@0 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x0 0x1000>;
+   qcom,ctx-asid = <0>;
+   interrupts = ;
+   };
+
+   /* gfx3d secure */
+   iommu-ctx@1000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x1000 0x1000>;
+   qcom,ctx-asid = <2>;
+   interrupts = ;
+   };
+
+   /* gfx3d priv */
+   iommu-ctx@2000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x2000 0x1000>;
+   qcom,ctx-asid = <1>;
+   interrupts = ;
+   };
+   };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x1000>,
-- 
2.44.0




[PATCH v3 0/4] MSM8976 MDSS/GPU/WCNSS support

2024-04-13 Thread Adam Skladowski
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.

Changes since v2

1. Disabled mdss_dsi nodes by default
2. Changed reg size of mdss_dsi0 to be equal on both
3. Added operating points to second mdss_dsi
4. Brought back required opp-supported-hw on adreno
5. Moved status under operating points on adreno

Changes since v1

1. Addressed feedback
2. Dropped already applied dt-bindings patches
3. Dropped sdc patch as it was submitted as part of other series
4. Dropped dt-bindings patch for Adreno, also separate now

Adam Skladowski (4):
  arm64: dts: qcom: msm8976: Add IOMMU nodes
  arm64: dts: qcom: msm8976: Add MDSS nodes
  arm64: dts: qcom: msm8976: Add Adreno GPU
  arm64: dts: qcom: msm8976: Add WCNSS node

 arch/arm64/boot/dts/qcom/msm8976.dtsi | 536 +-
 1 file changed, 532 insertions(+), 4 deletions(-)

-- 
2.44.0




[PATCH v2 4/4] arm64: dts: qcom: msm8976: Add WCNSS node

2024-04-01 Thread Adam Skladowski
Add node describing wireless connectivity subsystem.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 104 ++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 77670fce9b8f..41c748c78347 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -771,6 +771,36 @@ blsp2_i2c4_sleep: blsp2-i2c4-sleep-state {
drive-strength = <2>;
bias-disable;
};
+
+   wcss_wlan_default: wcss-wlan-default-state  {
+   wcss-wlan2-pins {
+   pins = "gpio40";
+   function = "wcss_wlan2";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan1-pins {
+   pins = "gpio41";
+   function = "wcss_wlan1";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan0-pins {
+   pins = "gpio42";
+   function = "wcss_wlan0";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+
+   wcss-wlan-pins {
+   pins = "gpio43", "gpio44";
+   function = "wcss_wlan";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+   };
};
 
gcc: clock-controller@180 {
@@ -1446,6 +1476,80 @@ blsp2_i2c4: i2c@7af8000 {
status = "disabled";
};
 
+   wcnss: remoteproc@a204000 {
+   compatible = "qcom,pronto-v3-pil", "qcom,pronto";
+   reg = <0x0a204000 0x2000>,
+ <0x0a202000 0x1000>,
+ <0x0a21b000 0x3000>;
+   reg-names = "ccu",
+   "dxe",
+   "pmu";
+
+   memory-region = <_fw_mem>;
+
+   interrupts-extended = < GIC_SPI 149 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 
IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+   power-domains = < MSM8976_VDDCX>,
+   < MSM8976_VDDMX>;
+   power-domain-names = "cx", "mx";
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   pinctrl-0 = <_wlan_default>;
+   pinctrl-names = "default";
+
+   status = "disabled";
+
+   wcnss_iris: iris {
+   /* Separate chip, compatible is board-specific 
*/
+   clocks = < RPM_SMD_RF_CLK2>;
+   clock-names = "xo";
+   };
+
+   smd-edge {
+   interrupts = ;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+   qcom,remote-pid = <4>;
+
+   label = "pronto";
+
+   wcnss_ctrl: wcnss {
+   compatible = "qcom,wcnss";
+   qcom,smd-channels = "WCNSS_CTRL";
+
+   

[PATCH v2 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU

2024-04-01 Thread Adam Skladowski
Add Adreno GPU node.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 6be310079f5b..77670fce9b8f 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -1074,6 +1074,71 @@ mdss_dsi1_phy: phy@1a96a00 {
};
};
 
+   adreno_gpu: gpu@1c0 {
+   compatible = "qcom,adreno-510.0", "qcom,adreno";
+
+   reg = <0x01c0 0x4>;
+   reg-names = "kgsl_3d0_reg_memory";
+
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+
+   clocks = < GCC_GFX3D_OXILI_CLK>,
+< GCC_GFX3D_OXILI_AHB_CLK>,
+< GCC_GFX3D_OXILI_GMEM_CLK>,
+< GCC_GFX3D_BIMC_CLK>,
+< GCC_GFX3D_OXILI_TIMER_CLK>,
+< GCC_GFX3D_OXILI_AON_CLK>;
+   clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer",
+ "alwayson";
+
+   power-domains = < OXILI_GX_GDSC>;
+
+   iommus = <_iommu 0>;
+
+   status = "disabled";
+
+   operating-points-v2 = <_opp_table>;
+
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = <_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = <_opp_svs>;
+   };
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   required-opps = <_opp_nom>;
+   };
+
+   opp-48000 {
+   opp-hz = /bits/ 64 <48000>;
+   required-opps = <_opp_nom_plus>;
+   };
+
+   opp-54000 {
+   opp-hz = /bits/ 64 <54000>;
+   required-opps = <_opp_turbo>;
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   required-opps = <_opp_turbo>;
+   };
+   };
+   };
+
apps_iommu: iommu@1ee {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee 0x3000>;
-- 
2.44.0




[PATCH v2 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes

2024-04-01 Thread Adam Skladowski
Add MDSS nodes to support displays on MSM8976 SoC.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 274 +-
 1 file changed, 270 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 8bdcc1438177..6be310079f5b 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -785,10 +785,10 @@ gcc: clock-controller@180 {
 
clocks = < RPM_SMD_XO_CLK_SRC>,
 < RPM_SMD_XO_A_CLK_SRC>,
-<0>,
-<0>,
-<0>,
-<0>;
+<_dsi0_phy 1>,
+<_dsi0_phy 0>,
+<_dsi1_phy 1>,
+<_dsi1_phy 0>;
clock-names = "xo",
  "xo_a",
  "dsi0pll",
@@ -808,6 +808,272 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   mdss: display-subsystem@1a0 {
+   compatible = "qcom,mdss";
+
+   reg = <0x01a0 0x1000>,
+ <0x01ab 0x3000>;
+   reg-names = "mdss_phys", "vbif_phys";
+
+   power-domains = < MDSS_GDSC>;
+   interrupts = ;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDSS_MDP_CLK>;
+   clock-names = "iface",
+ "bus",
+ "vsync",
+ "core";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   status = "disabled";
+
+   mdss_mdp: display-controller@1a01000 {
+   compatible = "qcom,msm8976-mdp5", "qcom,mdp5";
+   reg = <0x01a01000 0x89000>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <>;
+   interrupts = <0>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_VSYNC_CLK>,
+< GCC_MDP_TBU_CLK>,
+< GCC_MDP_RT_TBU_CLK>;
+   clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "tbu",
+ "tbu_rt";
+
+   operating-points-v2 = <_opp_table>;
+   power-domains = < MDSS_GDSC>;
+
+   iommus = <_iommu 22>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mdss_mdp5_intf1_out: endpoint {
+   remote-endpoint = 
<_dsi0_in>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mdss_mdp5_intf2_out: endpoint {
+   remote-endpoint = 
<_dsi1_in>;
+   };
+   };
+   };
+
+   mdp_opp_table: opp-table {
+  

[PATCH v2 1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes

2024-04-01 Thread Adam Skladowski
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.

Signed-off-by: Adam Skladowski 
---
 arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi 
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..8bdcc1438177 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -808,6 +808,87 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
 
+   apps_iommu: iommu@1ee {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   reg = <0x01ee 0x3000>;
+   ranges  = <0 0x01e2 0x2>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_APSS_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   qcom,iommu-secure-id = <17>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* VFE */
+   iommu-ctx@15000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x15000 0x1000>;
+   qcom,ctx-asid = <20>;
+   interrupts = ;
+   };
+
+   /* VENUS NS */
+   iommu-ctx@16000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x16000 0x1000>;
+   qcom,ctx-asid = <21>;
+   interrupts = ;
+   };
+
+   /* MDP0 */
+   iommu-ctx@17000 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x17000 0x1000>;
+   qcom,ctx-asid = <22>;
+   interrupts = ;
+   };
+   };
+
+   gpu_iommu: iommu@1f08000 {
+   compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+   ranges = <0 0x01f08000 0x8000>;
+
+   clocks = < GCC_SMMU_CFG_CLK>,
+< GCC_GFX3D_TCU_CLK>;
+   clock-names = "iface", "bus";
+
+   power-domains = < OXILI_CX_GDSC>;
+
+   qcom,iommu-secure-id = <18>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   #iommu-cells = <1>;
+
+   /* gfx3d user */
+   iommu-ctx@0 {
+   compatible = "qcom,msm-iommu-v2-ns";
+   reg = <0x0 0x1000>;
+   qcom,ctx-asid = <0>;
+   interrupts = ;
+   };
+
+   /* gfx3d secure */
+   iommu-ctx@1000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x1000 0x1000>;
+   qcom,ctx-asid = <2>;
+   interrupts = ;
+   };
+
+   /* gfx3d priv */
+   iommu-ctx@2000 {
+   compatible = "qcom,msm-iommu-v2-sec";
+   reg = <0x2000 0x1000>;
+   qcom,ctx-asid = <1>;
+   interrupts = ;
+   };
+   };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x1000>,
-- 
2.44.0




[PATCH v2 0/4] MSM8976 MDSS/GPU/WCNSS support

2024-04-01 Thread Adam Skladowski
This patch series provide support for display subsystem, gpu
and also adds wireless connectivity subsystem support.

Changes since v1

1. Addressed feedback
2. Dropped already applied dt-bindings patches
3. Dropped sdc patch as it was submitted as part of other series
4. Dropped dt-bindings patch for Adreno, also separate now

Adam Skladowski (4):
  arm64: dts: qcom: msm8976: Add IOMMU nodes
  arm64: dts: qcom: msm8976: Add MDSS nodes
  arm64: dts: qcom: msm8976: Add Adreno GPU
  arm64: dts: qcom: msm8976: Add WCNSS node

 arch/arm64/boot/dts/qcom/msm8976.dtsi | 524 +-
 1 file changed, 520 insertions(+), 4 deletions(-)

-- 
2.44.0




[PATCH 1/1] clk: qcom: smd-rpm: Restore msm8976 num_clk

2024-04-01 Thread Adam Skladowski
During rework somehow msm8976 num_clk got removed, restore it.

Fixes: d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus clocks")
Signed-off-by: Adam Skladowski 
---
 drivers/clk/qcom/clk-smd-rpm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
index 8602c02047d0..45c5255bcd11 100644
--- a/drivers/clk/qcom/clk-smd-rpm.c
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -768,6 +768,7 @@ static struct clk_smd_rpm *msm8976_clks[] = {
 
 static const struct rpm_smd_clk_desc rpm_clk_msm8976 = {
.clks = msm8976_clks,
+   .num_clks = ARRAY_SIZE(msm8976_clks),
.icc_clks = bimc_pcnoc_snoc_smmnoc_icc_clks,
.num_icc_clks = ARRAY_SIZE(bimc_pcnoc_snoc_smmnoc_icc_clks),
 };
-- 
2.44.0




[PATCH net] bpf: test_run: fix WARNING in format_decode

2023-11-21 Thread Edward Adam Davis
Confirm that skb->len is not 0 to ensure that skb length is valid.

Fixes: 114039b34201 ("bpf: Move skb->len == 0 checks into __bpf_redirect")
Reported-by: syzbot+e2c932aec5c8a6e1d...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis 
---
 net/bpf/test_run.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index c9fdcc5cdce1..78258a822a5c 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -845,6 +845,9 @@ static int convert___skb_to_skb(struct sk_buff *skb, struct 
__sk_buff *__skb)
 {
struct qdisc_skb_cb *cb = (struct qdisc_skb_cb *)skb->cb;
 
+   if (!skb->len)
+   return -EINVAL;
+
if (!__skb)
return 0;
 
-- 
2.26.1




Re: [PATCH] net: ethernet: ravb: Fix release of refclk

2021-04-19 Thread Adam Ford
On Mon, Apr 19, 2021 at 5:45 PM David Miller  wrote:
>
> From: Adam Ford 
> Date: Sat, 17 Apr 2021 08:23:29 -0500
>
> > The call to clk_disable_unprepare() can happen before priv is
> > initialized. This means moving clk_disable_unprepare out of
> > out_release into a new label.
> >
> > Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
> > Signed-off-by: Adam Ford 
> Thjis does not apply cleanly, please rebbase and resubmit.

Which branch should I use as the rebase?  I used net-next because
that's where the bug is, but I know it changes frequently.

>
> Please fix the formatting of your Fixes tag while you are at it, thank you.

no problem.  Sorry about that

adam


RE: [PATCH 4/7] mfd: da9052: Simplify getting of_device_id match data

2021-04-19 Thread Adam Thomson
On 19 April 2021 09:17, Krzysztof Kozlowski wrote:

> Use of_device_get_match_data() to make the code slightly smaller.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

Acked-by: Adam Thomson 

>  drivers/mfd/da9062-core.c | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index 8d913375152d..01f8e10dfa55 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -622,7 +623,6 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>   const struct i2c_device_id *id)
>  {
>   struct da9062 *chip;
> - const struct of_device_id *match;
>   unsigned int irq_base;
>   const struct mfd_cell *cell;
>   const struct regmap_irq_chip *irq_chip;
> @@ -635,15 +635,10 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
>   if (!chip)
>   return -ENOMEM;
> 
> - if (i2c->dev.of_node) {
> - match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
> - if (!match)
> - return -EINVAL;
> -
> - chip->chip_type = (uintptr_t)match->data;
> - } else {
> + if (i2c->dev.of_node)
> + chip->chip_type = (uintptr_t)of_device_get_match_data(
> >dev);
> + else
>   chip->chip_type = id->driver_data;
> - }
> 
>   i2c_set_clientdata(i2c, chip);
>   chip->dev = >dev;
> --
> 2.25.1



RE: [PATCH 3/7] mfd: da9052: Simplify getting of_device_id match data

2021-04-19 Thread Adam Thomson
On 19 April 2021 09:17, Krzysztof Kozlowski wrote:

> Use of_device_get_match_data() to make the code slightly smaller.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

Acked-by: Adam Thomson 

>  drivers/mfd/da9052-i2c.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
> index 47556d2d9abe..5d8ce8dca3fc 100644
> --- a/drivers/mfd/da9052-i2c.c
> +++ b/drivers/mfd/da9052-i2c.c
> @@ -154,13 +154,8 @@ static int da9052_i2c_probe(struct i2c_client *client,
>   return ret;
> 
>  #ifdef CONFIG_OF
> - if (!id) {
> - struct device_node *np = client->dev.of_node;
> - const struct of_device_id *deviceid;
> -
> - deviceid = of_match_node(dialog_dt_ids, np);
> - id = deviceid->data;
> - }
> + if (!id)
> + id = of_device_get_match_data(>dev);
>  #endif
> 
>   if (!id) {
> --
> 2.25.1



Re: [PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk

2021-04-17 Thread Adam Ford
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven  wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford  wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically.  Because the Versaclock is wired to provide the
> > AVB refclock, the device tree needs to reference it in order for the
> > driver to start the clock.
> >
> > Signed-off-by: Adam Ford 
>
> Reviewed-by: Geert Uytterhoeven 
> i.e. will queue in renesas-devel (with the typo fixed) once the DT
> bindings have been accepted.

Geert,

Since the refclk update and corresponding dt-bindings are in net-next,
are you OK applying the rest of the DT changes so they can get into
5.13?

adam
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds


[PATCH] net: ethernet: ravb: Fix release of refclk

2021-04-17 Thread Adam Ford
The call to clk_disable_unprepare() can happen before priv is
initialized. This means moving clk_disable_unprepare out of
out_release into a new label.

Fixes: 8ef7adc6beb2("net: ethernet: ravb: Enable optional refclk")
Signed-off-by: Adam Ford 

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 8c84c40ab9a0..64a545c98ff2 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2173,7 +2173,7 @@ static int ravb_probe(struct platform_device *pdev)
/* Set GTI value */
error = ravb_set_gti(ndev);
if (error)
-   goto out_release;
+   goto out_unprepare_refclk;
 
/* Request GTI loading */
ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
@@ -2192,7 +2192,7 @@ static int ravb_probe(struct platform_device *pdev)
"Cannot allocate desc base address table (size %d 
bytes)\n",
priv->desc_bat_size);
error = -ENOMEM;
-   goto out_release;
+   goto out_unprepare_refclk;
}
for (q = RAVB_BE; q < DBAT_ENTRY_NUM; q++)
priv->desc_bat[q].die_dt = DT_EOS;
@@ -2252,8 +2252,9 @@ static int ravb_probe(struct platform_device *pdev)
/* Stop PTP Clock driver */
if (chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
-out_release:
+out_unprepare_refclk:
clk_disable_unprepare(priv->refclk);
+out_release:
free_netdev(ndev);
 
pm_runtime_put(>dev);
-- 
2.25.1



RE: [RFC PATCH 2/2] ASoC: da732x: simplify code

2021-04-15 Thread Adam Thomson
On 15 April 2021 17:04, Mark Brown wrote:

> On Thu, Apr 15, 2021 at 04:00:48PM +0000, Adam Thomson wrote:
> > On 26 March 2021 22:16, Pierre-Louis Bossart wrote:
> 
> > Apologies for the delay in getting to this. The change looks fine to me,
> > although this part was EOL some time back, and I find it hard to believe 
> > anyone
> > out there has a board with this on. Wondering if it would make sense to
> remove
> > the driver permanently?
> 
> Unless it's actually getting in the way it's generally easier to just
> leave the driver than try to figure out if anyone is updating a system
> that uses it.

Fair enough. Just don't want to waste people's time with unnecessary updates :)


RE: [RFC PATCH 2/2] ASoC: da732x: simplify code

2021-04-15 Thread Adam Thomson
On 26 March 2021 22:16, Pierre-Louis Bossart wrote:

> cppcheck reports a false positive:
> 
> sound/soc/codecs/da732x.c:1161:25: warning: Either the condition
> 'indiv<0' is redundant or there is division by zero at line
> 1161. [zerodivcond]
>  fref = (da732x->sysclk / indiv);
> ^
> sound/soc/codecs/da732x.c:1158:12: note: Assuming that condition
> 'indiv<0' is not redundant
>  if (indiv < 0)
>^
> sound/soc/codecs/da732x.c:1161:25: note: Division by zero
>  fref = (da732x->sysclk / indiv);
> ^
> 
> The code is awfully convoluted/confusing and can be simplified with a
> single variable and the BIT macro.
> 
> Signed-off-by: Pierre-Louis Bossart 
> ---

Apologies for the delay in getting to this. The change looks fine to me,
although this part was EOL some time back, and I find it hard to believe anyone
out there has a board with this on. Wondering if it would make sense to remove
the driver permanently?

For the change at hand though:

Reviewed-by: Adam Thomson 

>  sound/soc/codecs/da732x.c | 17 ++---
>  sound/soc/codecs/da732x.h | 12 
>  2 files changed, 10 insertions(+), 19 deletions(-)
> 
> diff --git a/sound/soc/codecs/da732x.c b/sound/soc/codecs/da732x.c
> index d43ee7159ae0..42d6a3fc3af5 100644
> --- a/sound/soc/codecs/da732x.c
> +++ b/sound/soc/codecs/da732x.c
> @@ -168,30 +168,25 @@ static const struct reg_default da732x_reg_cache[] = {
>  static inline int da732x_get_input_div(struct snd_soc_component *component,
> int sysclk)
>  {
>   int val;
> - int ret;
> 
>   if (sysclk < DA732X_MCLK_10MHZ) {
> - val = DA732X_MCLK_RET_0_10MHZ;
> - ret = DA732X_MCLK_VAL_0_10MHZ;
> + val = DA732X_MCLK_VAL_0_10MHZ;
>   } else if ((sysclk >= DA732X_MCLK_10MHZ) &&
>   (sysclk < DA732X_MCLK_20MHZ)) {
> - val = DA732X_MCLK_RET_10_20MHZ;
> - ret = DA732X_MCLK_VAL_10_20MHZ;
> + val = DA732X_MCLK_VAL_10_20MHZ;
>   } else if ((sysclk >= DA732X_MCLK_20MHZ) &&
>   (sysclk < DA732X_MCLK_40MHZ)) {
> - val = DA732X_MCLK_RET_20_40MHZ;
> - ret = DA732X_MCLK_VAL_20_40MHZ;
> + val = DA732X_MCLK_VAL_20_40MHZ;
>   } else if ((sysclk >= DA732X_MCLK_40MHZ) &&
>   (sysclk <= DA732X_MCLK_54MHZ)) {
> - val = DA732X_MCLK_RET_40_54MHZ;
> - ret = DA732X_MCLK_VAL_40_54MHZ;
> + val = DA732X_MCLK_VAL_40_54MHZ;
>   } else {
>   return -EINVAL;
>   }
> 
>   snd_soc_component_write(component, DA732X_REG_PLL_CTRL, val);
> 
> - return ret;
> + return val;
>  }
> 
>  static void da732x_set_charge_pump(struct snd_soc_component *component,
> int state)
> @@ -1158,7 +1153,7 @@ static int da732x_set_dai_pll(struct
> snd_soc_component *component, int pll_id,
>   if (indiv < 0)
>   return indiv;
> 
> - fref = (da732x->sysclk / indiv);
> + fref = da732x->sysclk / BIT(indiv);
>   div_hi = freq_out / fref;
>   frac_div = (u64)(freq_out % fref) * 8192ULL;
>   do_div(frac_div, fref);
> diff --git a/sound/soc/codecs/da732x.h b/sound/soc/codecs/da732x.h
> index c5af17ee1516..c2f784c3f359 100644
> --- a/sound/soc/codecs/da732x.h
> +++ b/sound/soc/codecs/da732x.h
> @@ -48,14 +48,10 @@
>  #define  DA732X_MCLK_20MHZ   2000
>  #define  DA732X_MCLK_40MHZ   4000
>  #define  DA732X_MCLK_54MHZ   5400
> -#define  DA732X_MCLK_RET_0_10MHZ 0
> -#define  DA732X_MCLK_VAL_0_10MHZ 1
> -#define  DA732X_MCLK_RET_10_20MHZ1
> -#define  DA732X_MCLK_VAL_10_20MHZ2
> -#define  DA732X_MCLK_RET_20_40MHZ2
> -#define  DA732X_MCLK_VAL_20_40MHZ4
> -#define  DA732X_MCLK_RET_40_54MHZ3
> -#define  DA732X_MCLK_VAL_40_54MHZ8
> +#define  DA732X_MCLK_VAL_0_10MHZ 0
> +#define  DA732X_MCLK_VAL_10_20MHZ1
> +#define  DA732X_MCLK_VAL_20_40MHZ2
> +#define  DA732X_MCLK_VAL_40_54MHZ3
>  #define  DA732X_DAI_ID1  0
>  #define  DA732X_DAI_ID2  1
>  #define  DA732X_SRCCLK_PLL   0
> --
> 2.25.1



Re: [PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk

2021-04-14 Thread Adam Ford
On Tue, Apr 13, 2021 at 2:33 AM Geert Uytterhoeven  wrote:
>
> Hi Adam,
>
> On Mon, Apr 12, 2021 at 3:27 PM Adam Ford  wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them.  Add code to find the optional clock
> > and enable it when available.
> >
> > Signed-off-by: Adam Ford 
> > Reviewed-by: Andrew Lunn 
> >
> > ---
> > V4:  Eliminate the NULL check when disabling refclk, and add a line
> >  to disable the refclk if there is a failure after it's been
> >  initialized.
>
> Thanks for the update!
>
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > +   priv->refclk = devm_clk_get_optional(>dev, "refclk");
> > +   if (IS_ERR(priv->refclk)) {
> > +   error = PTR_ERR(priv->refclk);
> > +   goto out_release;
>
> Note that this will call clk_disable_unprepare() in case of failure, which is
> fine, as that function is a no-op in case of a failed clock.

Geert,

A bot reported that if I jump to out_release may try to free a clock
if some instances where priv isn't defined.
Currently, the priv->clk isn't freed either.  I have heard some
back-and-forth discussions in other threads on whether or not devm
functions auto free or not.

I'm fine with sending a V5 to make the free for the refclock happen
only when the priv has successfully initialized.  Should I also add
one for freeing priv->clk and change all the other goto out_release
commands to point to this new section?

I am thinking it would like something like:

free_refclk:
clk_disable_unprepare(priv->refclk);
free_clk;
clk_disable_unprepare(priv->clk);
out_release:
free_netdev(ndev);



adam
>
> > +   }
> > +   clk_prepare_enable(priv->refclk);
> > +
> > ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> > ndev->min_mtu = ETH_MIN_MTU;
> >
> > @@ -2244,6 +2251,7 @@ static int ravb_probe(struct platform_device *pdev)
> > if (chip_id != RCAR_GEN2)
> > ravb_ptp_stop(ndev);
> >  out_release:
> > +   clk_disable_unprepare(priv->refclk);
> > free_netdev(ndev);
> >
> > pm_runtime_put(>dev);
>
> Reviewed-by: Geert Uytterhoeven 
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds


[PATCH V4 2/2] net: ethernet: ravb: Enable optional refclk

2021-04-12 Thread Adam Ford
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them.  Add code to find the optional clock
and enable it when available.

Signed-off-by: Adam Ford 
Reviewed-by: Andrew Lunn 

---
V4:  Eliminate the NULL check when disabling refclk, and add a line
 to disable the refclk if there is a failure after it's been
 initialized.

V3:  Change 'avb' to 'AVB'
 Remove unnessary else statement and pointer maniupluation when
 enabling the refclock.
 Add disable_unprepare call in remove funtion.

V2:  The previous patch to fetch the fclk was dropped.  In its place
 is code to enable the refclk

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index cb47e68c1a3e..86a1eb0634e8 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -993,6 +993,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+   struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index eb0c03bdb12d..1409ae986aa2 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
 
+   priv->refclk = devm_clk_get_optional(>dev, "refclk");
+   if (IS_ERR(priv->refclk)) {
+   error = PTR_ERR(priv->refclk);
+   goto out_release;
+   }
+   clk_prepare_enable(priv->refclk);
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
 
@@ -2244,6 +2251,7 @@ static int ravb_probe(struct platform_device *pdev)
if (chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
 out_release:
+   clk_disable_unprepare(priv->refclk);
free_netdev(ndev);
 
pm_runtime_put(>dev);
@@ -2260,6 +2268,8 @@ static int ravb_remove(struct platform_device *pdev)
if (priv->chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
 
+   clk_disable_unprepare(priv->refclk);
+
dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
  priv->desc_bat_dma);
/* Set reset mode */
-- 
2.17.1



[PATCH V4 1/2] dt-bindings: net: renesas,etheravb: Add additional clocks

2021-04-12 Thread Adam Ford
The AVB driver assumes there is an external crystal, but it could
be clocked by other means.  In order to enable a programmable
clock, it needs to be added to the clocks list and enabled in the
driver.  Since there currently only one clock, there is no
clock-names list either.

Update bindings to add the additional optional clock, and explicitly
name both of them.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
Reviewed-by: Sergei Shtylyov 
---
V4:  No Change
V3:  No Change
V2:  No Change

diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml 
b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index 91ba96d43c6c..fe72a5598add 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -50,7 +50,16 @@ properties:
   interrupt-names: true
 
   clocks:
-maxItems: 1
+minItems: 1
+maxItems: 2
+items:
+  - description: AVB functional clock
+  - description: Optional TXC reference clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: refclk
 
   iommus:
 maxItems: 1
-- 
2.17.1



Re: [PATCH v1 0/7] imx-gpcv2 improvements

2021-04-09 Thread Adam Ford
On Wed, Apr 7, 2021 at 8:27 PM Peng Fan (OSS)  wrote:
>
> Hi Lucas,
>
> On 2021/4/8 6:13, Lucas Stach wrote:
> > Hi Adrien,
> >
> > I feel like I already mentioned to you some time ago that there is
> > already a much more complete patch series to add this functionality on
> > the list [1].
> >
> > If you want this functionality to go upstream, please help test and
> > extend this patch series.
> >
> > Regards,
> > Lucas
> >
> > [1] 
> > https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.st...@pengutronix.de/
>
> Would you share what's the issue that block this going forward?

Peng,

I know of a few.  One of them is mentioned in [1] above.  From what I
can tell, the dt-bindings have halted being able to enable the GPU and
USB power domains.  See [2] for some of that dialog.

The second part that I am aware is the blk-ctl being dependent on the
power domain and the power domain being dependent on the blk-ctl [3]
There was some discussion of using syscon to let the power-domain
finish coming up and then referencing the the power-domain from the
blk-ctl, but there was some disagreement [4] on that approach

I think Abel tried to create an IRC, but by the time I was able to
join the IRC, there was no activity.

[2] - 
https://lore.kernel.org/linux-arm-kernel/cahcn7xldked0g3fa9gap-xvkz-bymvcyn-8oebgnjbjycco...@mail.gmail.com/
[3] - https://lkml.org/lkml/2020/11/9/17
[4] - https://www.spinics.net/lists/arm-kernel/msg849032.html

>
> Thanks,
> Peng.
>
> >
> > Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> >> Hi,
> >>
> >> This patch set aims is to add the support of the i.MX8 MM power domains
> >> on the mainline kernel.
> >>
> >> To achieve this, I do several patches
> >>- Check errors when reading or writing registers (concerns i.MX8M base
> >>  implementation);
> >>- Fix power up/down sequence. Handshake was not checked and it was
> >>  not called at the appropriate time (concerns i.MX8M base
> >> implementaions);
> >>- Allow domains without power sequence control like the HSIOMIX of the
> >>  i.MX8MM.
> >>- Add some i.MX8MM domains (HSIO and OTGS);
> >>- Introduce quirks. For example, i.MX8MM OTG domains should not be
> >>  powered off (seen n the source code of th i.MX ATF). Quirks are
> >> easily upgrable for other cases.
> >>- Finally I defined power domains into the imx8mm.dtb file.
> >>
> >> I know that this kind of patch is rejected by NXP ut the other way
> >> (callin ATF directly) was also rejected.
> >>
> >> I also know that NXP is concerned abou adding hundred lines of codes for
> >> each new SOC but it' the way it works on Linux. And the "added code"
> >> mainly consist of adding structures, defines and generic methods for
> >> regmap.
> >>
> >> If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> >> i.MX8MM, i.MX8MN and i.MX8MP.
> >>
> >> Thanks,
> >>
> >> Adrien Grassein (7):
> >>soc: imx: gpcv2: check for errors when r/w registers
> >>soc: imx: gpcv2: Fix power up/down sequence
> >>soc: imx: gpcv2: allow domains without power sequence control
> >>dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> >>soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> >>soc: imx: gpcv2: add quirks to domains
> >>arm64: dts: imx8mm: add power-domains
> >>
> >>   .../bindings/power/fsl,imx-gpcv2.yaml |   7 +-
> >>   arch/arm64/boot/dts/freescale/imx8mm.dtsi |  35 ++
> >>   drivers/soc/imx/gpcv2.c   | 336 ++
> >>   include/dt-bindings/power/imx8mm-power.h  |  21 ++
> >>   4 files changed, 333 insertions(+), 66 deletions(-)
> >>   create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >>
> >
> >


Re: [PATCH v1 0/7] imx-gpcv2 improvements

2021-04-07 Thread Adam Ford
On Wed, Apr 7, 2021 at 5:13 PM Lucas Stach  wrote:
>
> Hi Adrien,
>
> I feel like I already mentioned to you some time ago that there is
> already a much more complete patch series to add this functionality on
> the list [1].
>
> If you want this functionality to go upstream, please help test and
> extend this patch series.
>
> Regards,
> Lucas
>
> [1] 
> https://lore.kernel.org/linux-arm-kernel/20201105174434.1817539-1-l.st...@pengutronix.de/

I took Lucas' code and attempted to build upon it to add Nano support.
At some point, someone from NXP thought it would get really hard to
read if we started filling that file with every supported SoC.
To help with that, I created a patch to split the gpcv2 code into a
gcpv2 core functions  with the individual SoC's having separate files
to help keep things a little cleaner, and easier to read:
gpcv2-imx7, gpcv2-imx8mq, gpcv2-imx8mm, and gpcv2-imx8mn, etc.
I was holding off on doing anything with it, because the dt-bindings
appeared to be stalled, and the attempt by Lucas to get the basic
functionality was stalled.

As of right now, it seems like without any changes, I can not get my
Mini or Nano to wake from sleep unless I use a U-Boot and ATF based on
NXP's custom branches.  When using the custom branches, I made some
additional patches to the gpcv2 to add a flag which would prevent
disabling USB OTG on Mini and Nano which appeared to help waking from
sleep, and it matched some of what NXP's custom ATF was doing.

I know there has been some concern about using syscon address the
resets and enables, but I took some work Marek did, and added to it by
adding some flags to the structure which could take the syscon and
write different values to the blk-ctl register depending on whether or
not it was a Mini or Nano (and probably Plus).   Using some of these,
I was able to get the dispmix to come out of reset and enable the
LCDIF on both Mini and Nano, but for some reason, any attempts to
enable the mipi domain were causing failures in other domains, so I
strilpped them out again.  I've withheld posting any of these for the
same reasons I withheld my other patches.

As soon as Lucas' patch [1] above or something similar gets accepted,
can rebase and submit a few of the patches I have.

adam
>
> Am Mittwoch, dem 07.04.2021 um 23:21 +0200 schrieb Adrien Grassein:
> > Hi,
> >
> > This patch set aims is to add the support of the i.MX8 MM power domains
> > on the mainline kernel.
> >
> > To achieve this, I do several patches
> >   - Check errors when reading or writing registers (concerns i.MX8M base
> > implementation);
> >   - Fix power up/down sequence. Handshake was not checked and it was
> > not called at the appropriate time (concerns i.MX8M base
> > implementaions);
> >   - Allow domains without power sequence control like the HSIOMIX of the
> > i.MX8MM.
> >   - Add some i.MX8MM domains (HSIO and OTGS);
> >   - Introduce quirks. For example, i.MX8MM OTG domains should not be
> > powered off (seen n the source code of th i.MX ATF). Quirks are
> > easily upgrable for other cases.
> >   - Finally I defined power domains into the imx8mm.dtb file.
> >
> > I know that this kind of patch is rejected by NXP ut the other way
> > (callin ATF directly) was also rejected.
> >
> > I also know that NXP is concerned abou adding hundred lines of codes for
> > each new SOC but it' the way it works on Linux. And the "added code"
> > mainly consist of adding structures, defines and generic methods for
> > regmap.
> >
> > If it's a real problem, maybe we can introduc a new "gpcv3" driver for
> > i.MX8MM, i.MX8MN and i.MX8MP.
> >
> > Thanks,
> >
> > Adrien Grassein (7):
> >   soc: imx: gpcv2: check for errors when r/w registers
> >   soc: imx: gpcv2: Fix power up/down sequence
> >   soc: imx: gpcv2: allow domains without power sequence control
> >   dt-bindings: power: fsl,imx-gpcv2: add definitions for i.MX8MM
> >   soc: imx: gpcv2: add HSIOMIX and USB domains for i.MX8MM
> >   soc: imx: gpcv2: add quirks to domains
> >   arm64: dts: imx8mm: add power-domains
> >
> >  .../bindings/power/fsl,imx-gpcv2.yaml |   7 +-
> >  arch/arm64/boot/dts/freescale/imx8mm.dtsi |  35 ++
> >  drivers/soc/imx/gpcv2.c   | 336 ++
> >  include/dt-bindings/power/imx8mm-power.h  |  21 ++
> >  4 files changed, 333 insertions(+), 66 deletions(-)
> >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> >
>
>


RE: [PATCH v1 2/6] usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply

2021-04-07 Thread Adam Thomson
On 06 April 2021 02:37, Badhri Jagan Sridharan wrote:

> tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt,
> port->pps_data.max_volt, port->pps_data.max_curr even before
> port partner accepts the requests. This leaves incorrect values
> in current_limit and supply_voltage that get exported by
> "tcpm-source-psy-". Solving this problem by caching the request
> values in req_min_volt, req_max_volt, req_max_curr, req_out_volt,
> req_op_curr. min_volt, max_volt, max_curr gets updated once the
> partner accepts the request. current_limit, supply_voltage gets updated
> once local port's tcpm enters SNK_TRANSITION_SINK when the accepted
> current_limit and supply_voltage is enforced.
> 
> Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan 
> ---

Reviewed-by: Adam Thomson 

>  drivers/usb/typec/tcpm/tcpm.c | 84 ---
>  1 file changed, 49 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 03eca5061132..d43774cc2ccf 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -269,11 +269,22 @@ struct pd_mode_data {
>  };
> 
>  struct pd_pps_data {
> + /* Actual min voltage at the local port */
>   u32 min_volt;
> + /* Requested min voltage to the port partner */
> + u32 req_min_volt;
> + /* Actual max voltage at the local port */
>   u32 max_volt;
> + /* Requested max voltage to the port partner */
> + u32 req_max_volt;
> + /* Actual max current at the local port */
>   u32 max_curr;
> - u32 out_volt;
> - u32 op_curr;
> + /* Requested max current of the port partner */
> + u32 req_max_curr;
> + /* Requested output voltage to the port partner */
> + u32 req_out_volt;
> + /* Requested operating current to the port partner */
> + u32 req_op_curr;
>   bool supported;
>   bool active;
>  };
> @@ -2498,8 +2509,8 @@ static void tcpm_pd_ctrl_request(struct tcpm_port
> *port,
>   break;
>   case SNK_NEGOTIATE_PPS_CAPABILITIES:
>   /* Revert data back from any requested PPS updates */
> - port->pps_data.out_volt = port->supply_voltage;
> - port->pps_data.op_curr = port->current_limit;
> + port->pps_data.req_out_volt = port->supply_voltage;
> + port->pps_data.req_op_curr = port->current_limit;
>   port->pps_status = (type == PD_CTRL_WAIT ?
>   -EAGAIN : -EOPNOTSUPP);
> 
> @@ -2548,8 +2559,11 @@ static void tcpm_pd_ctrl_request(struct tcpm_port
> *port,
>   break;
>   case SNK_NEGOTIATE_PPS_CAPABILITIES:
>   port->pps_data.active = true;
> - port->req_supply_voltage = port->pps_data.out_volt;
> - port->req_current_limit = port->pps_data.op_curr;
> + port->pps_data.min_volt = port-
> >pps_data.req_min_volt;
> + port->pps_data.max_volt = port-
> >pps_data.req_max_volt;
> + port->pps_data.max_curr = port-
> >pps_data.req_max_curr;
> + port->req_supply_voltage = port-
> >pps_data.req_out_volt;
> + port->req_current_limit = port->pps_data.req_op_curr;
>   tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
>   break;
>   case SOFT_RESET_SEND:
> @@ -3108,16 +3122,16 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
>   src = port->source_caps[src_pdo];
>   snk = port->snk_pdo[snk_pdo];
> 
> - port->pps_data.min_volt =
> max(pdo_pps_apdo_min_voltage(src),
> -   pdo_pps_apdo_min_voltage(snk));
> - port->pps_data.max_volt =
> min(pdo_pps_apdo_max_voltage(src),
> -   pdo_pps_apdo_max_voltage(snk));
> - port->pps_data.max_curr = min_pps_apdo_current(src, snk);
> - port->pps_data.out_volt = min(port->pps_data.max_volt,
> -   max(port->pps_data.min_volt,
> -   port->pps_data.out_volt));
> - port->pps_data.op_curr = min(port->pps_data.max_curr,
> -  port->pps_data.op_curr);
> + port->pps_d

RE: [PATCH v1 3/6] usb: typec: tcpm: update power supply once partner accepts

2021-04-07 Thread Adam Thomson
On 06 April 2021 02:37, Badhri Jagan Sridharan wrote:

> power_supply_changed needs to be called to notify clients
> after the partner accepts the requested values for the pps
> case.
> 
> Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan 
> ---

Missing commit information aside:

Reviewed-by: Adam Thomson 

>  drivers/usb/typec/tcpm/tcpm.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index d43774cc2ccf..7708b01009cb 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2564,6 +2564,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port
> *port,
>   port->pps_data.max_curr = port-
> >pps_data.req_max_curr;
>   port->req_supply_voltage = port-
> >pps_data.req_out_volt;
>   port->req_current_limit = port->pps_data.req_op_curr;
> + power_supply_changed(port->psy);
>   tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
>   break;
>   case SOFT_RESET_SEND:
> @@ -3132,7 +3133,6 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
> port-
> >pps_data.req_out_volt));
>   port->pps_data.req_op_curr = min(port->pps_data.max_curr,
>port->pps_data.req_op_curr);
> - power_supply_changed(port->psy);
>   }
> 
>   return src_pdo;
> @@ -3557,8 +3557,6 @@ static void tcpm_reset_port(struct tcpm_port *port)
>   port->sink_cap_done = false;
>   if (port->tcpc->enable_frs)
>   port->tcpc->enable_frs(port->tcpc, false);
> -
> - power_supply_changed(port->psy);
>  }
> 
>  static void tcpm_detach(struct tcpm_port *port)
> --
> 2.31.0.208.g409f899ff0-goog



RE: [PATCH v1 1/6] usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply

2021-04-07 Thread Adam Thomson
On 06 April 2021 02:37, Badhri Jagan Sridharan wrote:

> tcpm_pd_build_request overwrites current_limit and supply_voltage
> even before port partner accepts the requests. This leaves stale
> values in current_limit and supply_voltage that get exported by
> "tcpm-source-psy-". Solving this problem by caching the request
> values of current limit/supply voltage in req_current_limit
> and req_supply_voltage. current_limit/supply_voltage gets updated
> once the port partner accepts the request.
> 
> Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan 
> ---

Looks sensible, typo aside:

Reviewed-by: Adam Thomson 

>  drivers/usb/typec/tcpm/tcpm.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ca1fc77697fc..03eca5061132 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -389,7 +389,10 @@ struct tcpm_port {
>   unsigned int operating_snk_mw;
>   bool update_sink_caps;
> 
> - /* Requested current / voltage */
> + /* Requested current / voltage to the port partner */
> + u32 req_current_limit;
> + u32 req_supply_voltage;
> + /* Acutal current / voltage limit of the local port */
>   u32 current_limit;
>   u32 supply_voltage;
> 
> @@ -2435,8 +2438,8 @@ static void tcpm_pd_ctrl_request(struct tcpm_port
> *port,
>   case SNK_TRANSITION_SINK:
>   if (port->vbus_present) {
>   tcpm_set_current_limit(port,
> -port->current_limit,
> -port->supply_voltage);
> +port->req_current_limit,
> +
> port->req_supply_voltage);
>   port->explicit_contract = true;
>   tcpm_set_auto_vbus_discharge_threshold(port,
> 
> TYPEC_PWR_MODE_PD,
> @@ -2545,8 +2548,8 @@ static void tcpm_pd_ctrl_request(struct tcpm_port
> *port,
>   break;
>   case SNK_NEGOTIATE_PPS_CAPABILITIES:
>   port->pps_data.active = true;
> - port->supply_voltage = port->pps_data.out_volt;
> - port->current_limit = port->pps_data.op_curr;
> + port->req_supply_voltage = port->pps_data.out_volt;
> + port->req_current_limit = port->pps_data.op_curr;
>   tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
>   break;
>   case SOFT_RESET_SEND:
> @@ -3195,8 +3198,8 @@ static int tcpm_pd_build_request(struct tcpm_port
> *port, u32 *rdo)
>flags & RDO_CAP_MISMATCH ? " [mismatch]" : "");
>   }
> 
> - port->current_limit = ma;
> - port->supply_voltage = mv;
> + port->req_current_limit = ma;
> + port->req_supply_voltage = mv;
> 
>   return 0;
>  }
> --
> 2.31.0.208.g409f899ff0-goog



[PATCH 1/2] arm64: dts: imx8mn: Add spba1 bus

2021-04-05 Thread Adam Ford
The i.MX8MN has an SPBA bus which covers much of the audio, but
there is a second SPBA bus which covers many of the serial interfaces
like SPI and UARTs currently missing from the device tree. The reference
manual calls the bus handling the audio peripherals SPBA2, and the bus
handling the serial peripherals is called SPBA1.

Rename the existing spba bus to spba2 and add spba1.

Signed-off-by: Adam Ford 

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 4dac4da38f4c..e961acd237a8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -255,7 +255,7 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges;
 
-   spba: spba-bus@3000 {
+   spba2: spba-bus@3000 {
compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
@@ -681,80 +681,88 @@ aips3: bus@3080 {
#size-cells = <1>;
ranges;
 
-   ecspi1: spi@3082 {
-   compatible = "fsl,imx8mn-ecspi", 
"fsl,imx51-ecspi";
+   spba1: spba-bus@3080 {
+   compatible = "fsl,spba-bus", "simple-bus";
#address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x3082 0x1>;
-   interrupts = ;
-   clocks = < IMX8MN_CLK_ECSPI1_ROOT>,
-< IMX8MN_CLK_ECSPI1_ROOT>;
-   clock-names = "ipg", "per";
-   dmas = < 0 7 1>, < 1 7 2>;
-   dma-names = "rx", "tx";
-   status = "disabled";
-   };
+   #size-cells = <1>;
+   reg = <0x3080 0x10>;
+   ranges;
 
-   ecspi2: spi@3083 {
-   compatible = "fsl,imx8mn-ecspi", 
"fsl,imx51-ecspi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x3083 0x1>;
-   interrupts = ;
-   clocks = < IMX8MN_CLK_ECSPI2_ROOT>,
-< IMX8MN_CLK_ECSPI2_ROOT>;
-   clock-names = "ipg", "per";
-   dmas = < 2 7 1>, < 3 7 2>;
-   dma-names = "rx", "tx";
-   status = "disabled";
-   };
+   ecspi1: spi@3082 {
+   compatible = "fsl,imx8mn-ecspi", 
"fsl,imx51-ecspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x3082 0x1>;
+   interrupts = ;
+   clocks = < IMX8MN_CLK_ECSPI1_ROOT>,
+< IMX8MN_CLK_ECSPI1_ROOT>;
+   clock-names = "ipg", "per";
+   dmas = < 0 7 1>, < 1 7 2>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
-   ecspi3: spi@3084 {
-   compatible = "fsl,imx8mn-ecspi", 
"fsl,imx51-ecspi";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x3084 0x1>;
-   interrupts = ;
-   clocks = < IMX8MN_CLK_ECSPI3_ROOT>,
-< IMX8MN_CLK_ECSPI3_ROOT>;
-   clock-names = "ipg", "per";
-   dmas = < 4 7 1>, < 5 7 2>;
-   dma-names = "rx", "tx";
-  

[PATCH 2/2] arm64: dts: imx8mm: Add spba1 and spba2 buses

2021-04-05 Thread Adam Ford
The i.MX8MM reference manual shows there are two spba busses.
SPBA1 handles much of the serial interfaces, and SPBA2 covers much
of the audio.

Add both of them.

Signed-off-by: Adam Ford 

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index a27e02bee6b4..64aa38fd2b6e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -271,117 +271,125 @@ aips1: bus@3000 {
#size-cells = <1>;
ranges = <0x3000 0x3000 0x40>;
 
-   sai1: sai@3001 {
-   #sound-dai-cells = <0>;
-   compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-   reg = <0x3001 0x1>;
-   interrupts = ;
-   clocks = < IMX8MM_CLK_SAI1_IPG>,
-< IMX8MM_CLK_SAI1_ROOT>,
-< IMX8MM_CLK_DUMMY>, < 
IMX8MM_CLK_DUMMY>;
-   clock-names = "bus", "mclk1", "mclk2", "mclk3";
-   dmas = < 0 2 0>, < 1 2 0>;
-   dma-names = "rx", "tx";
-   status = "disabled";
-   };
+   spba2: spba-bus@3000 {
+   compatible = "fsl,spba-bus", "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x3000 0x10>;
+   ranges;
+
+   sai1: sai@3001 {
+   #sound-dai-cells = <0>;
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3001 0x1>;
+   interrupts = ;
+   clocks = < IMX8MM_CLK_SAI1_IPG>,
+< IMX8MM_CLK_SAI1_ROOT>,
+< IMX8MM_CLK_DUMMY>, < 
IMX8MM_CLK_DUMMY>;
+   clock-names = "bus", "mclk1", "mclk2", 
"mclk3";
+   dmas = < 0 2 0>, < 1 2 0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
-   sai2: sai@3002 {
-   #sound-dai-cells = <0>;
-   compatible = "fsl,imx8mm-sai", "fsl,imx8mq-sai";
-   reg = <0x3002 0x1>;
-   interrupts = ;
-   clocks = < IMX8MM_CLK_SAI2_IPG>,
-   < IMX8MM_CLK_SAI2_ROOT>,
-   < IMX8MM_CLK_DUMMY>, < 
IMX8MM_CLK_DUMMY>;
-   clock-names = "bus", "mclk1", "mclk2", "mclk3";
-   dmas = < 2 2 0>, < 3 2 0>;
-   dma-names = "rx", "tx";
-   status = "disabled";
-   };
+   sai2: sai@3002 {
+   #sound-dai-cells = <0>;
+   compatible = "fsl,imx8mm-sai", 
"fsl,imx8mq-sai";
+   reg = <0x3002 0x1>;
+   interrupts = ;
+   clocks = < IMX8MM_CLK_SAI2_IPG>,
+   < IMX8MM_CLK_SAI2_ROOT>,
+   < IMX8MM_CLK_DUMMY>, < 
IMX8MM_CLK_DUMMY>;
+   clock-names = "bus", "mclk1", "mclk2", 
"mclk3";
+   dmas = < 2 2 0>, < 3 2 0>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
-   sai3: sai@3003 {
-   #sound-dai-cells = <0>;
-   compatib

Re: [PATCH v1 0/2] Add imx8m power domain driver

2021-04-02 Thread Adam Ford
On Fri, Apr 2, 2021 at 1:16 PM Adrien Grassein
 wrote:
>
> Le ven. 2 avr. 2021 à 19:58, Abel Vesa  a écrit :
> >
> > On 21-04-02 19:48:41, Adrien Grassein wrote:
> > > Hi,
> > >
> > > Le ven. 2 avr. 2021 à 19:42, Abel Vesa  a écrit :
> > > >
> > > > On 21-04-02 18:45:04, Adrien Grassein wrote:
> > > > > Hi,
> > > > >
> > > > > this patch et aims to add the support of the i.MX 8 Power Domain 
> > > > > driver.
> > > > > Some devices (like usbotg2) can't work without this patch as their
> > > > > attached power domain are down.
> > > > >
> > > > > The original drivr was taken from le imx kernel and aapted to fit with
> > > > > the actual mainline (minor fixes).
> > > > >
> > > > > Thanks,
> > > > >
> > > >
> > > > Big NACK for the whole series.
> > > >
> > > > This approach has already been rejected upstream.
> > >
> > > So what is the correct approach?
> > > At this point otg2 node of imx8mm is not working at all (and blocks the 
> > > whole
> > > boot of the kernel)
> > >
> >
> > Have a look at this thread:
> >
> > https://lkml.org/lkml/2020/4/27/706
> >
> Understood, so I will try to update the gpc driver (at least for otg).

Thanks for doing that. I know Lucas tried a few times to get something
going.  I'm willing to adapt whatever work you do on the Mini toward
the Nano if you don't have time.

adam
>
> > > >
> > > > Plus, you changed the original author, this work was originally done by 
> > > > Jacky Bai.
> > >
> > > I have not changed this, the original author is not mentioned on the
> > > original patch.
> >
> > Here is the original commit:
> >
> > https://github.com/Freescale/linux-fslc/commit/7ebcf5ccf423afe4ccd9c53ef204018b0b653ce0
> >
> >
> > >
> > > >
> > > > > Adrien Grassein (2):
> > > > >   dt-bindings: power: Add documentation for imx8m power domain driver
> > > > >   soc: imx: add Power Domain driver for i.MX8M(M|N|P)
> > > > >
> > > > >  .../bindings/power/fsl,imx-power-domain.yaml  |  89 +++
> > > > >  MAINTAINERS   |  10 +
> > > > >  drivers/soc/imx/Kconfig   |   7 +
> > > > >  drivers/soc/imx/Makefile  |   1 +
> > > > >  drivers/soc/imx/imx8m_pm_domains.c| 233 
> > > > > ++
> > > > >  include/dt-bindings/power/imx8mm-power.h  |  21 ++
> > > > >  include/dt-bindings/power/imx8mn-power.h  |  15 ++
> > > > >  include/dt-bindings/power/imx8mp-power.h  |  28 +++
> > > > >  include/soc/imx/imx_sip.h |  12 +
> > > > >  9 files changed, 416 insertions(+)
> > > > >  create mode 100644 
> > > > > Documentation/devicetree/bindings/power/fsl,imx-power-domain.yaml
> > > > >  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
> > > > >  create mode 100644 include/dt-bindings/power/imx8mm-power.h
> > > > >  create mode 100644 include/dt-bindings/power/imx8mn-power.h
> > > > >  create mode 100644 include/dt-bindings/power/imx8mp-power.h
> > > > >  create mode 100644 include/soc/imx/imx_sip.h
> > > > >
> > > > > --
> > > > > 2.25.1
> > > > >
> > >
> > > Thanks,
>
> Thanks,
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [PATCH V5] dt-bindings: soc: imx: Add binding doc for spba bus

2021-04-01 Thread Adam Ford
On Mon, Nov 30, 2020 at 4:02 PM Rob Herring  wrote:
>
> On Wed, 18 Nov 2020 17:04:14 -0600, Adam Ford wrote:
> > Add binding doc for fsl,spba-bus.
> >
> > Signed-off-by: Adam Ford 
> > ---
> > make dt_binding_check -j8 |grep spba
> >   DTEXDocumentation/devicetree/bindings/bus/fsl,spba-bus.example.dts
> >   DTC Documentation/devicetree/bindings/bus/fsl,spba-bus.example.dt.yaml
> >   CHECK   Documentation/devicetree/bindings/bus/fsl,spba-bus.example.dt.yaml
> >
> > V5:  Rebase on 5.10-rc2 to be able to check yaml
> >  Add Reg entry
> >
> > V4:  Remove an accidental makefile change
> >  Move type:object under additional properties
> >
> > V3:  Rebase sample from aips-bus example
> >  Split off from series adding i.MX8M Nano functions to reduce noise
> >
> > V2:  Attempted to update yaml from feedback
> >
>
> Applied, thanks!

Rob,

I am not seeing this anywhere.  Can you tell me where this was
applied?  It's not appearing in Linux-next

adam


Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node

2021-03-31 Thread Adam Ford
On Tue, Dec 29, 2020 at 8:34 PM Peng Fan  wrote:
>
> > Subject: Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node
> >
> > On Tue, Dec 29, 2020 at 06:26:41AM -0600, Adam Ford wrote:
> > > On Tue, Dec 29, 2020 at 6:15 AM  wrote:
> > > >
> > > > From: Peng Fan 
> > > >
> > > > According to RM, there is a spba bus inside aips3 and aips1, add it.
> > > >
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 362
> > > > +++---
> > > >  1 file changed, 189 insertions(+), 173 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > index c824f2615fe8..91f85b8cee9a 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > > @@ -269,117 +269,125 @@ aips1: bus@3000 {
> > > > #size-cells = <1>;
> > > > ranges = <0x3000 0x3000
> > 0x40>;
> > > >
> > > > -   sai1: sai@3001 {
> > > > -   #sound-dai-cells = <0>;
> > > > -   compatible = "fsl,imx8mm-sai",
> > "fsl,imx8mq-sai";
> > > > -   reg = <0x3001 0x1>;
> > > > -   interrupts =  > IRQ_TYPE_LEVEL_HIGH>;
> > > > -   clocks = <
> > IMX8MM_CLK_SAI1_IPG>,
> > > > -<
> > IMX8MM_CLK_SAI1_ROOT>,
> > > > -<
> > IMX8MM_CLK_DUMMY>, < IMX8MM_CLK_DUMMY>;
> > > > -   clock-names = "bus", "mclk1",
> > "mclk2", "mclk3";
> > > > -   dmas = < 0 2 0>, <
> > 1 2 0>;
> > > > -   dma-names = "rx", "tx";
> > > > -   status = "disabled";
> > > > -   };
> > > > +   bus@3000 {
> > >
> > > There is already a bus@3000 (aips1), and I think the system
> > > doesn't like it when there are multiple busses with the same name.
> > >
> > > There was some discussion on fixing the 8mn [1], but it doesn't look
> > > like it went anywhere.
> > >
> > > I am guessing the Mini will need something similar to the nano.
> > >
> > > [1] -
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > >
> > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1607324004-1
> > 29
> > >
> > 60-1-git-send-email-shengjiu.wang%40nxp.com%2Fdata=04%7C01%7
> > Cpeng
> > > .fan%40nxp.com%7C970d320f3ef7413296ed08d8ac1486f9%7C686ea1d3bc
> > 2b4c6fa9
> > >
> > 2cd99c5c301635%7C0%7C0%7C637448551481206715%7CUnknown%7CTW
> > FpbGZsb3d8ey
> > >
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C200
> > >
> > 0sdata=xKgYHCDyitbUyTPKVuwQV%2FCoJvepCbdBJ1MD9vP%2B6MY
> > %3Dres
> > > erved=0
> >
> > Several replies from S.j. Wang are missing from LKML (and maybe
> > patchwork?) but we reached a conclusion:
>
> Thanks for the pointing, I'll give a look. If S.J take it, I'll leave it to 
> S.J.

Peng or S.J,

I don't see this was ever finished.  On the Nano, there is an spba-bus
under the aips1 bus, but I am not seeing anything on aips3 yet.   It
appears to have been abandoned.  The NXP kernel doesn't show either
spba-bus on the imx8m Mini either, but the documentation for the Mini
makes it look like it should work.  Do you want me to submit a patch
for any of this?

adam
>
> Thanks,
> Peng.
>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> > rnel.org%2Flinux-arm-kernel%2F20201208090601.GA8347%40kozik-lap%2F&
> > amp;data=04%7C01%7Cpeng.fan%40nxp.com%7C970d320f3ef7413296ed08
> > d8ac1486f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63744
> > 8551481206715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=nk
> > t0J5RtzA%2B29nK4aPnd434FNQV8MUZ%2F8Aq64o6hl6I%3Dreserved
> > =0
> >
> > Either you do some remapping of address space or just rename the "bus"
> > nodes (e.g. generic bus-1 or a specific spba-bus).
> >
> > Best regards,
> > Krzysztof


Re: [PATCH V3 4/5] net: ethernet: ravb: Enable optional refclk

2021-03-29 Thread Adam Ford
On Thu, Mar 4, 2021 at 2:08 AM Geert Uytterhoeven  wrote:
>
> Hi Adam,
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford  wrote:
> > For devices that use a programmable clock for the AVB reference clock,
> > the driver may need to enable them.  Add code to find the optional clock
> > and enable it when available.
> >
> > Signed-off-by: Adam Ford 
>
> Thanks for your patch!
>
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
> > goto out_release;
> > }
> >
> > +   priv->refclk = devm_clk_get_optional(>dev, "refclk");
> > +   if (IS_ERR(priv->refclk)) {
> > +   error = PTR_ERR(priv->refclk);
> > +   goto out_release;
> > +   }
> > +   clk_prepare_enable(priv->refclk);
> > +
>
> Shouldn't the reference clock be disabled in case of any failure below?
>
I'll generate a V4.

Should I just regenerate this patch since it seems like the rest are
OK, or should I regenerate the whole series?

adam
> > ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> > ndev->min_mtu = ETH_MIN_MTU;
> >
> > @@ -2260,6 +2267,9 @@ static int ravb_remove(struct platform_device *pdev)
> > if (priv->chip_id != RCAR_GEN2)
> > ravb_ptp_stop(ndev);
> >
> > +   if (priv->refclk)
> > +   clk_disable_unprepare(priv->refclk);
> > +
> > dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, 
> > priv->desc_bat,
> >   priv->desc_bat_dma);
> > /* Set reset mode */
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds


Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout

2021-03-24 Thread Adam Ford
On Mon, Mar 22, 2021 at 4:42 PM Abel Vesa  wrote:
>
> On 21-03-13 06:28:17, Adam Ford wrote:
> > Most if not all i.MX SoC's call a function which enables all UARTS.
> > This is a problem for users who need to re-parent the clock source,
> > because any attempt to change the parent results in an busy error
> > due to the fact that the clocks have been enabled already.
> >
> >   clk: failed to reparent uart1 to sys_pll1_80m: -16
> >
> > Instead of pre-initializing all UARTS, scan the device tree to see
> > which UART clocks are associated to stdout, and only enable those
> > UART clocks if it's needed early.  This will move initialization of
> > the remaining clocks until after the parenting of the clocks.
> >
> > When the clocks are shutdown, this mechanism will also disable any
> > clocks that were pre-initialized.
> >
> > Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate 
> > protection")
> > Suggested-by: Aisheng Dong 
> > Signed-off-by: Adam Ford 
> > Reviewed-by: Abel Vesa 
> > Tested-by: Ahmad Fatoum 
> >
> > ---
> > V4:  Check if of_stdout is available before using it.
> >  Re-align #ifdef to remove repeated code.
> > V3:  Return a method more closely related to upstream kernel but
> >  instead of passing an array of UART's, each SoC passes the max
> >  number of UART clocks is has.  The imx clock driver will create
> >  an array to enable on startup, and disable later.
> > V2:  Attempt to port driver from vendor kernel.
> > ---
> >  drivers/clk/imx/clk-imx25.c   | 12 +-
> >  drivers/clk/imx/clk-imx27.c   | 13 +--
> >  drivers/clk/imx/clk-imx35.c   | 10 +
> >  drivers/clk/imx/clk-imx5.c| 30 +++--
> >  drivers/clk/imx/clk-imx6q.c   | 16 +-
> >  drivers/clk/imx/clk-imx6sl.c  | 16 +-
> >  drivers/clk/imx/clk-imx6sll.c | 24 +---
> >  drivers/clk/imx/clk-imx6sx.c  | 16 +-
> >  drivers/clk/imx/clk-imx7d.c   | 22 +--
> >  drivers/clk/imx/clk-imx7ulp.c | 31 ++
> >  drivers/clk/imx/clk-imx8mm.c  | 18 ++-
> >  drivers/clk/imx/clk-imx8mn.c  | 18 ++-
> >  drivers/clk/imx/clk-imx8mp.c  | 17 +--
> >  drivers/clk/imx/clk-imx8mq.c  | 18 ++-
> >  drivers/clk/imx/clk.c | 41 +++
> >  drivers/clk/imx/clk.h |  4 ++--
> >  16 files changed, 54 insertions(+), 252 deletions(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
> > index a66cabfbf94f..66192fe0a898 100644
> > --- a/drivers/clk/imx/clk-imx25.c
> > +++ b/drivers/clk/imx/clk-imx25.c
> > @@ -73,16 +73,6 @@ enum mx25_clks {
> >
> >  static struct clk *clk[clk_max];
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [uart_ipg_per],
> > - [uart1_ipg],
> > - [uart2_ipg],
> > - [uart3_ipg],
> > - [uart4_ipg],
> > - [uart5_ipg],
> > - NULL
> > -};
> > -
> >  static int __init __mx25_clocks_init(void __iomem *ccm_base)
> >  {
> >   BUG_ON(!ccm_base);
> > @@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem 
> > *ccm_base)
> >*/
> >   clk_set_parent(clk[cko_sel], clk[ipg]);
> >
> > - imx_register_uart_clocks(uart_clks);
> > + imx_register_uart_clocks(6);
> >
> >   return 0;
> >  }
> > diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
> > index 5585ded8b8c6..56a5fc402b10 100644
> > --- a/drivers/clk/imx/clk-imx27.c
> > +++ b/drivers/clk/imx/clk-imx27.c
> > @@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", 
> > "mpll", };
> >  static struct clk *clk[IMX27_CLK_MAX];
> >  static struct clk_onecell_data clk_data;
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [IMX27_CLK_PER1_GATE],
> > - [IMX27_CLK_UART1_IPG_GATE],
> > - [IMX27_CLK_UART2_IPG_GATE],
> > - [IMX27_CLK_UART3_IPG_GATE],
> > - [IMX27_CLK_UART4_IPG_GATE],
> > - [IMX27_CLK_UART5_IPG_GATE],
> > - [IMX27_CLK_UART6_IPG_GATE],
> > - NULL
> > -};
> > -
> >  static void __init _mx27_clocks_init(unsigned long fref)
> >  {
> >   BUG_ON(!ccm);
> > @@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
> >
> >   clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GA

Re: [PATCH v5 00/14] Add BLK_CTL support for i.MX8MP

2021-03-22 Thread Adam Ford
 could request the power domain.
The power domain soft-resets and enables bus clock (vis syscon)
After successful enabling of power-domain, the LCDIF requests the soft
reset and respective clock bits (also via syscon) similar to how [1]
and [2] do it for the Hantro VPU.

The syscon node could be a common node similar to what was done in
[2], and multiple consumers could control when each soft-reset and
clock-enable get activated.  I know it's probably more of an abuse of
the syscon system, but having the individual drivers control the order
of operations might be safer than trying to create a one-size-fits-all
driver.

adam
[1] - 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210318082046.51546-4-benjamin.gaign...@collabora.com/
[2] - 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210318082046.51546-14-benjamin.gaign...@collabora.com/


Re: drivers/char/rust_example fails to load 2021-03-20 builds

2021-03-22 Thread Adam Bratschi-Kaye
> How to tell "use older parts in toolchain"?
> Yeah, probably a Rust newbie question, still a sincere question.
> Was a older version installed? How to tell `rustup` to keep old
> versions? Was done with a cargo.toml entry? Or with file
> `rust-toolchain`?  Please tell   (Please spoon feed me ;-)

Using `rust-toolchain.toml` should work.
Another option would be to override the default version for the given
directory with
`rustup override set nightly-2021-02-20`.

You could also set the global default `rustc` to a specific nightly release:
`rustup default nightly-2021-02-20`.

More info here: https://rust-lang.github.io/rustup/overrides.html


Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout

2021-03-20 Thread Adam Ford
On Sun, Mar 14, 2021 at 4:40 AM Ahmad Fatoum  wrote:
>
> On 13.03.21 16:16, Ahmad Fatoum wrote:
> >> +/* i.MX boards use device trees now.  For build tests without CONFIG_OF, 
> >> do nothing */
> >> +#ifdef CONFIG_OF
> >>  if (imx_keep_uart_clocks) {
> >>  int i;
> >>
> >> -imx_uart_clocks = clks;
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_prepare_enable(*imx_uart_clocks[i]);
> >> +imx_uart_clocks = kcalloc(clk_count, sizeof(struct clk *), 
> >> GFP_KERNEL);
> >> +
> >> +if (!of_stdout)
> >> +return;
> >
> > Memory leak. Just do if (imx_keep_uart_clocks && of_stdout)
>
> Please dismiss. I overlooked that you free it in a later initcall.

Abel,

Are you OK with this?  I also have a V5 posted [1] which does what
Ahmad suggested.

Either of these will fix reparenting issues, but I need this for
Bluetooth to operate correctly, because both beacon imx8mn and imx8mn
kits switch the UART parent to an 80MHz clock in order to run at
4Mbps.

thank you,

adam
>
> >>  static int __init imx_clk_disable_uart(void)
> >>  {
> >> -if (imx_keep_uart_clocks && imx_uart_clocks) {
> >> +if (imx_keep_uart_clocks && imx_enabled_uart_clocks) {
> >>  int i;
> >>
> >> -for (i = 0; imx_uart_clocks[i]; i++)
> >> -clk_disable_unprepare(*imx_uart_clocks[i]);
> >> +for (i = 0; i < imx_enabled_uart_clocks; i++) {
> >> +clk_disable_unprepare(imx_uart_clocks[i]);
> >> +clk_put(imx_uart_clocks[i]);
> >> +};
> >> +kfree(imx_uart_clocks);
> >>  }
>
> --
> Pengutronix e.K.   | |
> Steuerwalder Str. 21   | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-

2021-03-19 Thread Adam Thomson
On 18 March 2021 20:40, Badhri Jagan Sridharan wrote:

> > Regarding selecting PDOs or PPS APDOs, surely we should only notify of a
> change
> > when we reach SNK_READY which means a new contract has been established?
> Until
> > that point it's possible any requested change could be rejected so why 
> > inform
> > clients before we know the settings have taken effect? I could be missing
> > something here as it's been a little while since I delved into this, but 
> > this
> > doesn't seem to make sense to me.
> 
> I was trying to keep the power_supply_changed call close to the
> variables which are used to infer the power supply property values.
> Since port->pps_data.max_curr is already updated here and that's used
> to infer the CURRENT_MAX a client could still read this before the
> request goes through right ?

Actually that's fair but I think the problem here relates to 'max_curr' not
being reset if the SRC rejects our request when we're swapping between one PPS
APDO and another PPS APDO. I think the 'max_curr' value should be reverted back
to the value for the existing PPS APDO we were already using. I suspect the same
might be true of 'min_volt' and 'max_volt' as well, now I look at it. It might
actually be prudent to have pending PPS data based on a request, which is only
committed as active once ACCEPT has been received.

Regarding power_supply_changed() though, I still think we should only notify of
a change when the requested change has been accepted by the source, in relation
to these values as they should reflect the real, in-use voltage and current
values.



RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-

2021-03-18 Thread Adam Thomson
On 17 March 2021 18:13, Badhri Jagan Sridharan wrote:

> tcpm-source-psy- does not invoke power_supply_changed API when
> one of the published power supply properties is changed.
> power_supply_changed needs to be called to notify
> userspace clients(uevents) and kernel clients.
> 
> Fixes: f2a8aa053c176("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan 
> Reviewed-by: Guenter Roeck 
> Reviewed-by: Heikki Krogerus 
> ---
> Changes since V1:
> - Fixed commit message as per Guenter's suggestion
> - Added Reviewed-by tags
> - cc'ed stable
> ---
>  drivers/usb/typec/tcpm/tcpm.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 11d0c40bc47d..e8936ea17f80 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -945,6 +945,7 @@ static int tcpm_set_current_limit(struct tcpm_port *port,
> u32 max_ma, u32 mv)
> 
>   port->supply_voltage = mv;
>   port->current_limit = max_ma;
> + power_supply_changed(port->psy);
> 
>   if (port->tcpc->set_current_limit)
>   ret = port->tcpc->set_current_limit(port->tcpc, max_ma, mv);
> @@ -2931,6 +2932,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> int *sink_pdo,
> 
>   port->pps_data.supported = false;
>   port->usb_type = POWER_SUPPLY_USB_TYPE_PD;
> + power_supply_changed(port->psy);
> 
>   /*
>* Select the source PDO providing the most power which has a
> @@ -2955,6 +2957,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
> int *sink_pdo,
>   port->pps_data.supported = true;
>   port->usb_type =
>   POWER_SUPPLY_USB_TYPE_PD_PPS;
> + power_supply_changed(port->psy);
>   }
>   continue;
>   default:
> @@ -3112,6 +3115,7 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
> port->pps_data.out_volt));
>   port->pps_data.op_curr = min(port->pps_data.max_curr,
>port->pps_data.op_curr);
> + power_supply_changed(port->psy);
>   }
> 
>   return src_pdo;

Regarding selecting PDOs or PPS APDOs, surely we should only notify of a change
when we reach SNK_READY which means a new contract has been established? Until
that point it's possible any requested change could be rejected so why inform
clients before we know the settings have taken effect? I could be missing
something here as it's been a little while since I delved into this, but this
doesn't seem to make sense to me.

> @@ -3347,6 +3351,7 @@ static int tcpm_set_charge(struct tcpm_port *port, bool
> charge)
>   return ret;
>   }
>   port->vbus_charge = charge;
> + power_supply_changed(port->psy);
>   return 0;
>  }
> 
> @@ -3530,6 +3535,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
>   port->try_src_count = 0;
>   port->try_snk_count = 0;
>   port->usb_type = POWER_SUPPLY_USB_TYPE_C;
> + power_supply_changed(port->psy);

This is already taken care of at the end of this function, isn't it?

>   port->nr_sink_caps = 0;
>   port->sink_cap_done = false;
>   if (port->tcpc->enable_frs)
> @@ -5957,7 +5963,7 @@ static int tcpm_psy_set_prop(struct power_supply
> *psy,
>   ret = -EINVAL;
>   break;
>   }
> -
> + power_supply_changed(port->psy);
>   return ret;
>  }
> 
> @@ -6110,6 +6116,7 @@ struct tcpm_port *tcpm_register_port(struct device
> *dev, struct tcpc_dev *tcpc)
>   err = devm_tcpm_psy_register(port);
>   if (err)
>   goto out_role_sw_put;
> + power_supply_changed(port->psy);
> 
>   port->typec_port = typec_register_port(port->dev, >typec_caps);
>   if (IS_ERR(port->typec_port)) {
> --
> 2.31.0.rc2.261.g7f71774620-goog



Re: [PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk

2021-03-18 Thread Adam Ford
On Thu, Mar 4, 2021 at 2:04 AM Geert Uytterhoeven  wrote:
>
> On Wed, Feb 24, 2021 at 12:52 PM Adam Ford  wrote:
> > The AVB refererence clock assumes an external clock that runs
>
> reference
>
> > automatically.  Because the Versaclock is wired to provide the
> > AVB refclock, the device tree needs to reference it in order for the
> > driver to start the clock.
> >
> > Signed-off-by: Adam Ford 
>
> Reviewed-by: Geert Uytterhoeven 
> i.e. will queue in renesas-devel (with the typo fixed) once the DT
> bindings have been accepted.
>

Who do I need to ping to get the DT bindings accepted?  They have an
acked-by from Rob.

adam

> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds


RE: [PATCH v6 1/1] mfd: da9063: Support SMBus and I2C mode

2021-03-17 Thread Adam Thomson
On 16 March 2021 16:23, Mark Jonas wrote:

> From: Hubert Streidl 
> 
> By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> means the PMIC will automatically reset the interface when the clock
> signal ceases for more than the SMBus timeout of 35 ms.
> 
> If the I2C driver / device is not capable of creating atomic I2C
> transactions, a context change can cause a ceasing of the clock signal.
> This can happen if for example a real-time thread is scheduled. Then
> the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently
> a write message could end up in the wrong register. This could cause
> unpredictable system behavior.
> 
> The DA9063 PMIC also supports an I2C compliant mode for the 2-wire
> interface. This mode does not reset the interface when the clock
> signal ceases. Thus the problem depicted above does not occur.
> 
> This patch tests for the bus functionality "I2C_FUNC_I2C". It can
> reasonably be assumed that the bus cannot obey SMBus timings if
> this functionality is set. SMBus commands most probably are emulated
> in this case which is prone to the latency issue described above.
> 
> This patch enables the I2C bus mode if I2C_FUNC_I2C is set or
> otherwise keeps the default SMBus mode.
> 
> Signed-off-by: Hubert Streidl 
> Signed-off-by: Mark Jonas 

Thanks for your efforts on this Mark.


Re: unknown NMI on AMD Rome

2021-03-16 Thread Adam Borowski
On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote:
> hi,
> when running 'perf top' on AMD Rome (/proc/cpuinfo below)
> with fedora 33 kernel 5.10.22-200.fc33.x86_64
> 
> we got unknown NMI messages:
> 
> [  226.700160] Uhhuh. NMI received for unknown reason 3d on CPU 90.
> [  226.700162] Do you have a strange power saving mode enabled?
> [  226.700163] Dazed and confused, but trying to continue
> 
> also when discussing ths with Borislav, he managed to reproduce easily
> on his AMD Rome machine

Likewise, 3c on Pinnacle Ridge.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄


RE: [PATCH 07/23] ASoC: da7219-aad: remove useless initialization

2021-03-15 Thread Adam Thomson
On 12 March 2021 18:23, Pierre-Louis Bossart wrote:

> cppcheck warning:
> 
> sound/soc/codecs/da7219-aad.c:118:22: style: Variable 'ret' is
> assigned a value that is never used. [unreadVariable]
>  int report = 0, ret = 0;
>  ^
> 
> Signed-off-by: Pierre-Louis Bossart 

Acked-by: Adam Thomson 


Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax

2021-03-13 Thread Adam Borowski
On Sat, Mar 13, 2021 at 11:24:00AM -0500, Neal Gompa wrote:
> On Sat, Mar 13, 2021 at 8:09 AM Adam Borowski  wrote:
> >
> > On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > > > DAX on btrfs has been attempted[1]. Of course, we could not
> > >
> > > But why?  A completeness fetish?  I don't understand why you decided
> > > to do this work.
> >
> > * xfs can shapshot only single files, btrfs entire subvolumes
> > * btrfs-send|receive
> > * enumeration of changed parts of a file
> 
> XFS cannot do snapshots since it lacks metadata COW. XFS reflinking is
> primarily for space efficiency.

A reflink is a single-file snapshot.

My work team really wants this very patchset -- reflinks on DAX allow
backups and/or checkpointing, without stopping the world (there's a single
file, "pool", here).

Besides, you can still get poor-man's whole-subvolume(/directory)
snapshots by manually walking the tree and reflinking everything.
That's not atomic -- but rsync isn't atomic either.  That's enough for
eg. dnf/dpkg purposes.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ NADIE anticipa la inquisición de españa!
⠈⠳⣄


[PATCH V5] clk: imx: Fix reparenting of UARTs not associated with stdout

2021-03-13 Thread Adam Ford
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.

  clk: failed to reparent uart1 to sys_pll1_80m: -16

Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early.  This will move initialization of
the remaining clocks until after the parenting of the clocks.

When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.

Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong 
Signed-off-by: Adam Ford 
Reviewed-by: Abel Vesa 
Tested-by: Ahmad Fatoum 

---
V5:  Combine of_stdout with check for imx_keep_uart_clocks to
 reduce code lines and prevent memory leak.
V4:  Check if of_stdout is available before using it.
 Re-align #ifdef to remove repeated code.
V3:  Return a method more closely related to upstream kernel but
 instead of passing an array of UART's, each SoC passes the max
 number of UART clocks is has.  The imx clock driver will create
 an array to enable on startup, and disable later.
V2:  Attempt to port driver from vendor kernel.
---
 drivers/clk/imx/clk-imx25.c   | 12 +--
 drivers/clk/imx/clk-imx27.c   | 13 +---
 drivers/clk/imx/clk-imx35.c   | 10 +
 drivers/clk/imx/clk-imx5.c| 30 +++---
 drivers/clk/imx/clk-imx6q.c   | 16 +-
 drivers/clk/imx/clk-imx6sl.c  | 16 +-
 drivers/clk/imx/clk-imx6sll.c | 24 +
 drivers/clk/imx/clk-imx6sx.c  | 16 +-
 drivers/clk/imx/clk-imx7d.c   | 22 +--
 drivers/clk/imx/clk-imx7ulp.c | 31 ++-
 drivers/clk/imx/clk-imx8mm.c  | 18 ++--
 drivers/clk/imx/clk-imx8mn.c  | 18 ++--
 drivers/clk/imx/clk-imx8mp.c  | 17 +--
 drivers/clk/imx/clk-imx8mq.c  | 18 ++--
 drivers/clk/imx/clk.c | 40 ++-
 drivers/clk/imx/clk.h |  4 ++--
 16 files changed, 52 insertions(+), 253 deletions(-)

diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [uart_ipg_per],
-   [uart1_ipg],
-   [uart2_ipg],
-   [uart3_ipg],
-   [uart4_ipg],
-   [uart5_ipg],
-   NULL
-};
-
 static int __init __mx25_clocks_init(void __iomem *ccm_base)
 {
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
 */
clk_set_parent(clk[cko_sel], clk[ipg]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(6);
 
return 0;
 }
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
 static struct clk *clk[IMX27_CLK_MAX];
 static struct clk_onecell_data clk_data;
 
-static struct clk ** const uart_clks[] __initconst = {
-   [IMX27_CLK_PER1_GATE],
-   [IMX27_CLK_UART1_IPG_GATE],
-   [IMX27_CLK_UART2_IPG_GATE],
-   [IMX27_CLK_UART3_IPG_GATE],
-   [IMX27_CLK_UART4_IPG_GATE],
-   [IMX27_CLK_UART5_IPG_GATE],
-   [IMX27_CLK_UART6_IPG_GATE],
-   NULL
-};
-
 static void __init _mx27_clocks_init(unsigned long fref)
 {
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
 
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(7);
 
imx_print_silicon_rev("i.MX27", mx27_revision());
 }
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [ipg],
-   [uart1_gate],
-   [uart2_gate],
-   [uart3_gate],
-   NULL
-};
-
 static void __init _mx35_clocks_init(void)
 {
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
 */
clk_prepare_enable(clk[scc_gate]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(4);
 
imx_print_silicon_rev("i.MX35", mx35_revision());
 }
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/

Re: [PATCH v2 00/10] fsdax,xfs: Add reflink support for fsdax

2021-03-13 Thread Adam Borowski
On Wed, Mar 10, 2021 at 02:26:43PM +, Matthew Wilcox wrote:
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > DAX on btrfs has been attempted[1]. Of course, we could not
> 
> But why?  A completeness fetish?  I don't understand why you decided
> to do this work.

* xfs can shapshot only single files, btrfs entire subvolumes
* btrfs-send|receive
* enumeration of changed parts of a file


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢠⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).


[PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout

2021-03-13 Thread Adam Ford
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.

  clk: failed to reparent uart1 to sys_pll1_80m: -16

Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early.  This will move initialization of
the remaining clocks until after the parenting of the clocks.

When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.

Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong 
Signed-off-by: Adam Ford 
Reviewed-by: Abel Vesa 
Tested-by: Ahmad Fatoum 

---
V4:  Check if of_stdout is available before using it.
 Re-align #ifdef to remove repeated code.
V3:  Return a method more closely related to upstream kernel but
 instead of passing an array of UART's, each SoC passes the max
 number of UART clocks is has.  The imx clock driver will create
 an array to enable on startup, and disable later.
V2:  Attempt to port driver from vendor kernel.
---
 drivers/clk/imx/clk-imx25.c   | 12 +-
 drivers/clk/imx/clk-imx27.c   | 13 +--
 drivers/clk/imx/clk-imx35.c   | 10 +
 drivers/clk/imx/clk-imx5.c| 30 +++--
 drivers/clk/imx/clk-imx6q.c   | 16 +-
 drivers/clk/imx/clk-imx6sl.c  | 16 +-
 drivers/clk/imx/clk-imx6sll.c | 24 +---
 drivers/clk/imx/clk-imx6sx.c  | 16 +-
 drivers/clk/imx/clk-imx7d.c   | 22 +--
 drivers/clk/imx/clk-imx7ulp.c | 31 ++
 drivers/clk/imx/clk-imx8mm.c  | 18 ++-
 drivers/clk/imx/clk-imx8mn.c  | 18 ++-
 drivers/clk/imx/clk-imx8mp.c  | 17 +--
 drivers/clk/imx/clk-imx8mq.c  | 18 ++-
 drivers/clk/imx/clk.c | 41 +++
 drivers/clk/imx/clk.h |  4 ++--
 16 files changed, 54 insertions(+), 252 deletions(-)

diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [uart_ipg_per],
-   [uart1_ipg],
-   [uart2_ipg],
-   [uart3_ipg],
-   [uart4_ipg],
-   [uart5_ipg],
-   NULL
-};
-
 static int __init __mx25_clocks_init(void __iomem *ccm_base)
 {
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
 */
clk_set_parent(clk[cko_sel], clk[ipg]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(6);
 
return 0;
 }
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
 static struct clk *clk[IMX27_CLK_MAX];
 static struct clk_onecell_data clk_data;
 
-static struct clk ** const uart_clks[] __initconst = {
-   [IMX27_CLK_PER1_GATE],
-   [IMX27_CLK_UART1_IPG_GATE],
-   [IMX27_CLK_UART2_IPG_GATE],
-   [IMX27_CLK_UART3_IPG_GATE],
-   [IMX27_CLK_UART4_IPG_GATE],
-   [IMX27_CLK_UART5_IPG_GATE],
-   [IMX27_CLK_UART6_IPG_GATE],
-   NULL
-};
-
 static void __init _mx27_clocks_init(unsigned long fref)
 {
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
 
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(7);
 
imx_print_silicon_rev("i.MX27", mx27_revision());
 }
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [ipg],
-   [uart1_gate],
-   [uart2_gate],
-   [uart3_gate],
-   NULL
-};
-
 static void __init _mx35_clocks_init(void)
 {
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
 */
clk_prepare_enable(clk[scc_gate]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(4);
 
imx_print_silicon_rev("i.MX35", mx35_revision());
 }
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/clk-imx5.c
index 01e079b81026..e4493846454d 100644
--- a/drivers/clk/imx/clk-imx5.c
+++ b/drivers/clk/imx/clk-imx5.c
@@ 

Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-03-10 Thread Adam Ford
On Wed, Mar 10, 2021 at 4:25 PM Abel Vesa  wrote:
>
> On 21-03-03 10:31:19, Abel Vesa wrote:
> > On 21-03-02 13:03:04, Adam Ford wrote:
> > > On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa  wrote:
> > > >
> > > > On 21-02-13 08:44:28, Adam Ford wrote:
> > > > > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford  wrote:
> > > > > >
> > > > > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa  wrote:
> > > > > > >
> > > > > > > On 21-01-21 10:56:17, Sascha Hauer wrote:
> > > > > > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote:
> > > > > > > > > On 21-01-20 16:50:01, Sascha Hauer wrote:
> > > > > > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote:
> > > > > > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote:
> > > > > > > > > > > > Hi Abel,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote:
> > > > > > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > TBH, I'm against the idea of having to call 
> > > > > > > > > > > > > > > consumer API from a clock provider driver.
> > > > > > > > > > > > > > > I'm still investigating a way of moving the uart 
> > > > > > > > > > > > > > > clock control calls in drivers/serial/imx,
> > > > > > > > > > > > > > > where they belong.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > That makes sense.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just a thought. The uart clock used for console 
> > > > > > > > > > > > > remains on from u-boot,
> > > > > > > > > > > > > so maybe it's enough to just add the 
> > > > > > > > > > > > > CLK_IGNORE_UNUSED flag to all the
> > > > > > > > > > > > > uart root clocks and remove the prepare/enable calls 
> > > > > > > > > > > > > for uart clocks
> > > > > > > > > > > > > for good. I don't really have a way to test it right 
> > > > > > > > > > > > > now, but maybe
> > > > > > > > > > > > > you could give it a try.
> > > > > > > > > > > >
> > > > > > > > > > > > That would mean that UART clocks will never be 
> > > > > > > > > > > > disabled, regardless of
> > > > > > > > > > > > whether they are used for console or not. That doesn't 
> > > > > > > > > > > > sound very
> > > > > > > > > > > > appealing.
> > > > > > > > > > >
> > > > > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is 
> > > > > > > > > > > the one used for
> > > > > > > > > > > the console. Later on, when the serial driver probes, it 
> > > > > > > > > > > will enable it itself.
> > > > > > > > > > >
> > > > > > > > > > > Unless I'm missing something, this is exactly what we 
> > > > > > > > > > > need.
> > > > > > > > > >
> > > > > > > > > > It might enable it, but with CLK_IGNORE_UNUSED t

MaxLinear, please maintain your drivers was Re: [PATCH] leds: lgm: fix gpiolib dependency

2021-03-09 Thread Adam Borowski
On Tue, Mar 09, 2021 at 08:39:10PM +0100, Pavel Machek wrote:
> > I'd like people from Intel to contact me. There's more to fix there,
> > and AFAICT original author went away.
> 
> The following message to  was
> undeliverable.

> : Recipient
> +address rejected: User unknown in virtual mailbox table'

> commit c3987cd2bca34ddfec69027acedb2fae5ffcf7a0
> Author: Amireddy Mallikarjuna reddy 

I asked around, and got told Mallikarjuna has been "sold" to MaxLinear,
together with the rest of the Connected Home Division.  So he most likely
still works on this stuff, just under a different banner.

> If someone knows how to contact the author, that would be welcome.

Alas, no idea about his MaxLinear address.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄


RE: [PATCH v4] mfd: da9063: Support SMBus and I2C mode

2021-03-09 Thread Adam Ward
Hi Lee,

Tidy, but I've noticed the logic got inverted along the way:

> On Tue 09 Mar 2021, Lee Jones wrote:
> On Tue, 09 Mar 2021, Mark Jonas wrote:
> This is my suggestion:
> 
>   /* If SMBus Mode is not available, enter Two-Wire Mode */
>   if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {

Determine bus *is* I2C, so assume SMBus timings not supported...
if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {

>   ret = regmap_update_bits(da9063->regmap, DA9063_REG_CONFIG_J,
>DA9063_TWOWIRE_TO,  DA9063_TWOWIRE_TO);

...and *clear* the (currently set by default) timeout bit:
 DA9063_TWOWIRE_TO,  0);

>   if (ret < 0) {
>   dev_err(da9063->dev, "Failed to set Two-Wire Bus
> Mode\n");
>   return -EIO;
>   }
>   }

I think you're right to exclude a case; vendor motivation to override the TO 
default seems inherently trustworthy.

Best regards,
Adam



Re: [PATCH v3 0/5] Reset driver for IMX8MQ VPU hardware block

2021-03-04 Thread Adam Ford
On Wed, Mar 3, 2021 at 5:24 PM Philipp Zabel  wrote:
>
> On Wed, 2021-03-03 at 16:20 +0100, Benjamin Gaignard wrote:
> > Le 03/03/2021 à 15:17, Philipp Zabel a écrit :
> > > Hi Benjamin,
> > >
> > > On Mon, 2021-03-01 at 16:17 +0100, Benjamin Gaignard wrote:
> > > > The two VPUs inside IMX8MQ share the same control block which can be see
> > > > as a reset hardware block.
> > > This isn't a reset controller though. The control block also contains
> > > clock gates of some sort and a filter register for the featureset fuses.
> > > Those shouldn't be manipulated via the reset API.

This driver is very similar to several other patches for clk_blk
control [1] which contain both resets and clock-enables on the
i.MX8MP, i.MX8MM and i.MX8MN.  In those cases, there are some specific
power domain controls that are needed, but I wonder if the approach to
creating resets and clock enables could be used in a similar way if
the IMX8MQ doesn't have the same quirks.  In the case of the i.MX8M
Mini, I think it has the same VPU.

[1] - 
https://patchwork.kernel.org/project/linux-clk/patch/1599560691-3763-12-git-send-email-abel.v...@nxp.com/

adam
> >
> > They are all part of the control block and of the reset process for this
> > hardware that why I put them here. I guess it is border line :-)
>
> I'm pushing back to keep the reset control framework focused on
> controlling reset lines. Every side effect (such as the asymmetric clock
> ungating) in a random driver makes it harder to reason about behaviour
> at the API level, and to review patches for hardware I am not familiar
> with.
>
> > > > In order to be able to add the second VPU (for HECV decoding) it will be
> > > > more handy if the both VPU drivers instance don't have to share the
> > > > control block registers. This lead to implement it as an independ reset
> > > > driver and to change the VPU driver to use it.
> > > Why not switch to a syscon regmap for the control block? That should
> > > also allow to keep backwards compatibility with the old binding with
> > > minimal effort.
> >
> > I will give a try in this direction.
>
> Thank you.
>
> > > > Please note that this series break the compatibility between the DTB and
> > > > kernel. This break is limited to IMX8MQ SoC and is done when the driver
> > > > is still in staging directory.
> > > I know in this case we are pretty sure there are no users of this
> > > binding except for a staging driver, but it would still be nice to keep
> > > support for the deprecated binding, to avoid the requirement of updating
> > > kernel and DT in lock-step.
> >
> > If I want to use a syscon (or a reset) the driver must not ioremap the 
> > "ctrl"
> > registers. It means that "ctrl" has to be removed from the driver requested
> > reg-names (imx8mq_reg_names[]). Doing that break the kernel/DT 
> > compatibility.
> > Somehow syscon and "ctrl" are exclusive.
>
> The way the driver is set up currently, yes. You could add a bit of
> platform specific probe code, though, that would set up the regmap
> either by calling
> syscon_regmap_lookup_by_phandle();
> for the new binding, or, if the phandle is not available, fall back to
> platform_get_resource_byname(..., "ctrl");
> devm_ioremap_resource();
> devm_regmap_init_mmio();
> for the old binding.
> The actual codec .reset and variant .runtime_resume ops could be
> identical then.
>
> regards
> Philipp
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-03-02 Thread Adam Ford
On Mon, Feb 15, 2021 at 7:06 AM Abel Vesa  wrote:
>
> On 21-02-13 08:44:28, Adam Ford wrote:
> > On Wed, Feb 3, 2021 at 3:22 PM Adam Ford  wrote:
> > >
> > > On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa  wrote:
> > > >
> > > > On 21-01-21 10:56:17, Sascha Hauer wrote:
> > > > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote:
> > > > > > On 21-01-20 16:50:01, Sascha Hauer wrote:
> > > > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote:
> > > > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote:
> > > > > > > > > Hi Abel,
> > > > > > > > >
> > > > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote:
> > > > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote:
> > > > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa 
> > > > > > > > > > >  wrote:
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > TBH, I'm against the idea of having to call consumer 
> > > > > > > > > > > > API from a clock provider driver.
> > > > > > > > > > > > I'm still investigating a way of moving the uart clock 
> > > > > > > > > > > > control calls in drivers/serial/imx,
> > > > > > > > > > > > where they belong.
> > > > > > > > > > >
> > > > > > > > > > > That makes sense.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Just a thought. The uart clock used for console remains on 
> > > > > > > > > > from u-boot,
> > > > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag 
> > > > > > > > > > to all the
> > > > > > > > > > uart root clocks and remove the prepare/enable calls for 
> > > > > > > > > > uart clocks
> > > > > > > > > > for good. I don't really have a way to test it right now, 
> > > > > > > > > > but maybe
> > > > > > > > > > you could give it a try.
> > > > > > > > >
> > > > > > > > > That would mean that UART clocks will never be disabled, 
> > > > > > > > > regardless of
> > > > > > > > > whether they are used for console or not. That doesn't sound 
> > > > > > > > > very
> > > > > > > > > appealing.
> > > > > > > >
> > > > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one 
> > > > > > > > used for
> > > > > > > > the console. Later on, when the serial driver probes, it will 
> > > > > > > > enable it itself.
> > > > > > > >
> > > > > > > > Unless I'm missing something, this is exactly what we need.
> > > > > > >
> > > > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be
> > > > > > > disabled again when a port is closed after usage
> > > > > >
> > > > > > OK, tell me what I'm getting wrong in the following scenario:
> > > > > >
> > > > > > U-boot leaves the console uart clock enabled. All the other ones 
> > > > > > are disabled.
> > > > > >
> > > > > > Kernel i.MX clk driver registers the uart clocks with flag 
> > > > > > CLK_IGNORE_UNUSED.
> > > > >
> > > > > I was wrong at that point. I originally thought the kernel will never
> > > > > disable these clocks, but in fact it only leaves them enabled during 
> > > > > the
> > > > > clk_disable_unused call.
> > > > >
> > > > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late 
> > > > > already.
> > > > > I just chatted with Lucas and he told me what the original problem was
> > > > &g

[PATCH V3 5/5] arm64: dts: renesas: beacon kits: Setup AVB refclk

2021-02-24 Thread Adam Ford
The AVB refererence clock assumes an external clock that runs
automatically.  Because the Versaclock is wired to provide the
AVB refclock, the device tree needs to reference it in order for the
driver to start the clock.

Signed-off-by: Adam Ford 
---
V3:  New to series

diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi 
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index 8d3a4d6ee885..75355c354c38 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -53,6 +53,8 @@  {
phy-handle = <>;
rx-internal-delay-ps = <1800>;
tx-internal-delay-ps = <2000>;
+   clocks = < CPG_MOD 812>, < 4>;
+   clock-names = "fck", "refclk";
status = "okay";
 
phy0: ethernet-phy@0 {
-- 
2.25.1



[PATCH V3 4/5] net: ethernet: ravb: Enable optional refclk

2021-02-24 Thread Adam Ford
For devices that use a programmable clock for the AVB reference clock,
the driver may need to enable them.  Add code to find the optional clock
and enable it when available.

Signed-off-by: Adam Ford 
---
V3:  Change 'avb' to 'AVB'
 Remove unnessary else statement and pointer maniupluation when 
 enabling the refclock. 
 Add disable_unprepare call in remove funtion.
  
V2:  The previous patch to fetch the fclk was dropped.  In its place
 is code to enable the refclk

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index 7453b17a37a2..ff363797bd2b 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -994,6 +994,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+   struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index bd30505fbc57..614448e6eb24 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,13 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
 
+   priv->refclk = devm_clk_get_optional(>dev, "refclk");
+   if (IS_ERR(priv->refclk)) {
+   error = PTR_ERR(priv->refclk);
+   goto out_release;
+   }
+   clk_prepare_enable(priv->refclk);
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
 
@@ -2260,6 +2267,9 @@ static int ravb_remove(struct platform_device *pdev)
if (priv->chip_id != RCAR_GEN2)
ravb_ptp_stop(ndev);
 
+   if (priv->refclk)
+   clk_disable_unprepare(priv->refclk);
+
dma_free_coherent(ndev->dev.parent, priv->desc_bat_size, priv->desc_bat,
  priv->desc_bat_dma);
/* Set reset mode */
-- 
2.25.1



[PATCH V3 2/5] ARM: dts: renesas: Add fck to etheravb-rcar-gen2 clock-names list

2021-02-24 Thread Adam Ford
The bindings have been updated to support two clocks, but the
original clock now requires the name fck.  Add a clock-names
list in the device tree with fck in it.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
---
V3:  No Change
V2:  No Change

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 6a78c813057b..6b922f664fcd 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -750,6 +750,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7742_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f444e418f408..084bf3e039cf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7743_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 0442aad4f9db..d01eba99ceb0 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7744_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0f14ac22921d..d0d45a369047 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -645,6 +645,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7745_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 691b1a131c87..ae90a001d663 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -537,6 +537,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b0569b4ea5c8..af9cd3324f4c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -768,6 +768,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7790_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87f0d6dc3e5a..2354af7fa83f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -728,6 +728,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7791_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index f5b299bfcb23..60c184ab1b49 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dt

[PATCH V3 1/5] dt-bindings: net: renesas,etheravb: Add additional clocks

2021-02-24 Thread Adam Ford
The AVB driver assumes there is an external crystal, but it could
be clocked by other means.  In order to enable a programmable
clock, it needs to be added to the clocks list and enabled in the
driver.  Since there currently only one clock, there is no
clock-names list either.

Update bindings to add the additional optional clock, and explicitly
name both of them.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
---
V3:  No Change
V2:  No Change

diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml 
b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index de9dd574a2f9..7b32363ad8b4 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -49,7 +49,16 @@ properties:
   interrupt-names: true
 
   clocks:
-maxItems: 1
+minItems: 1
+maxItems: 2
+items:
+  - description: AVB functional clock
+  - description: Optional TXC reference clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: refclk
 
   iommus:
 maxItems: 1
-- 
2.25.1



[PATCH V3 3/5] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list

2021-02-24 Thread Adam Ford
The bindings have been updated to support two clocks, but the
original clock now requires the name fck.  Add a clock-names
list in the device tree with fck in it.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
---
V3:  No Change
V2:  No Change

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d64fb8b1b86c..ec4feb7df775 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1127,6 +1127,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 5b05474dc272..1ff62b2be1f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -1001,6 +1001,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774B1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 20fa3caa050e..a4d9c6b31574 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -957,6 +957,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774C0_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 8eb006cbd9af..fec5839163ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -1230,6 +1230,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774E1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index 5c39152e4570..1e622ab8a044 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -1312,6 +1312,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 25d947a81b29..a3d1c33cbc1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -1188,6 +1188,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7796_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index e8c31ebec097..55a3ba3c844f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -1144,6 +1144,7 @@ avb: ethernet@e680 {
  

[PATCH] arm64: dts: imx8mn-beacon: Enable SDR104 on WiFi SDIO interface

2021-02-14 Thread Adam Ford
Enable 100Mhz and 200MHz pinmux and corrsesponding voltage supplies
to enable SDR104 on usdhc1 connecting the WiFi chip.

Signed-off-by: Adam Ford 

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index de2cd0e3201c..c35eeaff958f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -262,8 +262,12 @@ bluetooth {
  {
#address-cells = <1>;
#size-cells = <0>;
-   pinctrl-names = "default";
+   pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
+   pinctrl-1 = <_usdhc1_100mhz>;
+   pinctrl-2 = <_usdhc1_200mhz>;
+   vmmc-supply = <_reg>;
+   vqmmc-supply = <_reg>;
bus-width = <4>;
non-removable;
cap-power-off-card;
-- 
2.25.1



Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-02-13 Thread Adam Ford
On Wed, Feb 3, 2021 at 3:22 PM Adam Ford  wrote:
>
> On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa  wrote:
> >
> > On 21-01-21 10:56:17, Sascha Hauer wrote:
> > > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote:
> > > > On 21-01-20 16:50:01, Sascha Hauer wrote:
> > > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote:
> > > > > > On 21-01-20 16:13:05, Sascha Hauer wrote:
> > > > > > > Hi Abel,
> > > > > > >
> > > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote:
> > > > > > > > On 21-01-18 08:00:43, Adam Ford wrote:
> > > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa  
> > > > > > > > > wrote:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > TBH, I'm against the idea of having to call consumer API 
> > > > > > > > > > from a clock provider driver.
> > > > > > > > > > I'm still investigating a way of moving the uart clock 
> > > > > > > > > > control calls in drivers/serial/imx,
> > > > > > > > > > where they belong.
> > > > > > > > >
> > > > > > > > > That makes sense.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Just a thought. The uart clock used for console remains on from 
> > > > > > > > u-boot,
> > > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to 
> > > > > > > > all the
> > > > > > > > uart root clocks and remove the prepare/enable calls for uart 
> > > > > > > > clocks
> > > > > > > > for good. I don't really have a way to test it right now, but 
> > > > > > > > maybe
> > > > > > > > you could give it a try.
> > > > > > >
> > > > > > > That would mean that UART clocks will never be disabled, 
> > > > > > > regardless of
> > > > > > > whether they are used for console or not. That doesn't sound very
> > > > > > > appealing.
> > > > > >
> > > > > > AFAIK, the only uart clock that is enabled by u-boot is the one 
> > > > > > used for
> > > > > > the console. Later on, when the serial driver probes, it will 
> > > > > > enable it itself.
> > > > > >
> > > > > > Unless I'm missing something, this is exactly what we need.
> > > > >
> > > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be
> > > > > disabled again when a port is closed after usage
> > > >
> > > > OK, tell me what I'm getting wrong in the following scenario:
> > > >
> > > > U-boot leaves the console uart clock enabled. All the other ones are 
> > > > disabled.
> > > >
> > > > Kernel i.MX clk driver registers the uart clocks with flag 
> > > > CLK_IGNORE_UNUSED.
> > >
> > > I was wrong at that point. I originally thought the kernel will never
> > > disable these clocks, but in fact it only leaves them enabled during the
> > > clk_disable_unused call.
> > >
> > > However, when CLK_IGNORE_UNUSED becomes relevant it's too late already.
> > > I just chatted with Lucas and he told me what the original problem was
> > > that his patch solved.
> > >
> > > The problem comes when an unrelated device and the earlycon UART have
> > > the same parent clocks. The parent clock is enabled, but it's reference
> > > count is zero. Now when the unrelated device probes and toggles its
> > > clocks then the shared parent clock will be disabled due to the
> > > reference count being zero. Next time earlycon prints a character the
> > > system hangs because the UART gates are still enabled, but their parent
> > > clocks no longer are.
> > >
> >
> > Hmm, that is indeed a problem. That's why I think there should be some
> > kind of NOCACHE flag for almost all the types of clocks. For example,
> > in this case, it makes sense for the core to check the bit in the register
> > and then disable the pare

Re: [PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-02-10 Thread Adam Ford
On Wed, Feb 10, 2021 at 2:18 PM Rob Herring  wrote:
>
> On Sun, Feb 07, 2021 at 12:51:38PM -0600, Adam Ford wrote:
> > There are two registers which can set the load capacitance for
> > XTAL1 and XTAL2. These are optional registers when using an
> > external crystal.  Since XTAL1 and XTAL2 will set to the same value,
> > update the binding to support a single property called
> > xtal-load-femtofarads.
> >
> > Signed-off-by: Adam Ford 
> > ---
> > V3:  No Change
> > V2:  No Change
> >
> > A couple people suggested that I not use the $ref, but without it,
> > the bindings check failed with errors.
> >
> > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > index 2ac1131fd922..c268debe5b8d 100644
> > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > @@ -59,6 +59,12 @@ properties:
> >  minItems: 1
> >  maxItems: 2
> >
> > +  idt,xtal-load-femtofarads:
> > +$ref: /schemas/types.yaml#/definitions/uint32
>
> Don't need a type with standard unit suffix.

If I remove that line, the binding check fails.

adam
>
> > +minimum: 9000
> > +maximum: 22760
> > +description: Optional load capacitor for XTAL1 and XTAL2
> > +
> >  patternProperties:
> >"^OUT[1-4]$":
> >  type: object
> > --
> > 2.25.1
> >


RE: [PATCH v4] mfd: da9063: Support SMBus and I2C mode

2021-02-09 Thread Adam Thomson
On 08 February 2021 15:28, Mark Jonas wrote:

> From: Hubert Streidl 
> 
> By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> means the PMIC will automatically reset the interface when the clock
> signal ceases for more than the SMBus timeout of 35 ms.
> 
> If the I2C driver / device is not capable of creating atomic I2C
> transactions, a context change can cause a ceasing of the clock signal.
> This can happen if for example a real-time thread is scheduled. Then
> the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently
> a write message could end up in the wrong register. This could cause
> unpredictable system behavior.
> 
> The DA9063 PMIC also supports an I2C compliant mode for the 2-wire
> interface. This mode does not reset the interface when the clock
> signal ceases. Thus the problem depicted above does not occur.
> 
> This patch tests for the bus functionality "I2C_FUNC_I2C". It can
> reasonably be assumed that the bus cannot obey SMBus timings if
> this functionality is set. SMBus commands most probably are emulated
> in this case which is prone to the latency issue described above.
> 
> This patch enables the I2C bus mode if I2C_FUNC_I2C is set or
> otherwise enables the SMBus mode for a native SMBus controller
> which doesn't have I2C_FUNC_I2C set.
> 
> Signed-off-by: Hubert Streidl 
> Signed-off-by: Mark Jonas 

Thanks for your efforts. Looks sensible to me, so:

Reviewed-by: Adam Thomson 


Re: TLS for 5.10

2021-02-08 Thread Adam Borowski
On Mon, Feb 08, 2021 at 07:08:05AM +, Wadepohl, Wolfram wrote:
> I'm sad to hear that 5.10 has still an EOL of Dec, 2022. We are in
> development of our 1st GNU/Linux based System,  50k devices for IoT.
[...]
> In general a 2 year support for embedded systems in automation is not a
> reasonable thing. Nevertheless the CIP project has commited to 5.10 as the
> next SLTS kernel.
[...]
> What can we do as a very small development team to support an extended LTS
> period of 5.10.?

The two years are a minimal promise from Greg.  Debian is using 5.10 for
upcoming Bullseye, thus even if Greg won't extend (99% chance he will), Ben
Hutchings will continue the support for as long as Debian Bullseye is alive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.


[PATCH V3 2/2] clk: vc5: Add support for optional load capacitance

2021-02-07 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Parse the device tree and set the
corresponding registers accordingly.

Signed-off-by: Adam Ford 
---
V3:  Fix whitespace.  Use regmap_update_bits instead of performing
 a manual read-modify-write.
V2:  Make the math subtract 9000 since we have a DIV_ROUND_CLOSEST
 This also allows us to remove the check for 9430 since values
 between 9000 and 9430 will round up and down.
 Make write VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP
 a read-modify-write to not worry about the contents of
 bits[1:0].
 
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..344cd6c61188 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,63 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
 }
 
+static int vc5_map_cap_value(u32 femtofarads)
+{
+   int mapped_value;
+
+   /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+   if (femtofarads < 9000 || femtofarads > 22760)
+   return -EINVAL;
+
+   /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange.  With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+   mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9000, 430);
+
+   /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32.  In reality, this means
+* the real mapped value should be 11b.  In other cases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+   if (mapped_value > 31)
+   mapped_value = 0x3f;
+   else
+   mapped_value <<= 1;
+
+   return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct 
vc5_driver_data *vc5)
+{
+   u32 value;
+   int mapped_value;
+
+   if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+   mapped_value = vc5_map_cap_value(value);
+   if (mapped_value < 0)
+   return mapped_value;
+
+   /*
+* The mapped_value is really the high 6 bits of
+* VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP, so
+* shift the value 2 places.
+*/
+   regmap_update_bits(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, ~0x03, 
mapped_value << 2);
+   regmap_update_bits(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, ~0x03, 
mapped_value << 2);
+   }
+
+   return 0;
+}
+
 static int vc5_update_slew(struct device_node *np_output,
   struct vc5_out_data *clk_out)
 {
@@ -884,6 +941,13 @@ static int vc5_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return -EINVAL;
}
 
+   /* Configure Optional Loading Capacitance for external XTAL */
+   if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+   ret = vc5_update_cap_load(client->dev.of_node, vc5);
+   if (ret)
+   goto err_clk_register;
+   }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
-- 
2.25.1



[PATCH V3 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-02-07 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Since XTAL1 and XTAL2 will set to the same value,
update the binding to support a single property called
xtal-load-femtofarads.

Signed-off-by: Adam Ford 
---
V3:  No Change
V2:  No Change

A couple people suggested that I not use the $ref, but without it,
the bindings check failed with errors.

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
index 2ac1131fd922..c268debe5b8d 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
@@ -59,6 +59,12 @@ properties:
 minItems: 1
 maxItems: 2
 
+  idt,xtal-load-femtofarads:
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 9000
+maximum: 22760
+description: Optional load capacitor for XTAL1 and XTAL2
+
 patternProperties:
   "^OUT[1-4]$":
 type: object
-- 
2.25.1



Re: [PATCH 3/4] thermal: ti-soc-thermal: Simplify polling with iopoll

2021-02-06 Thread Adam Ford
On Fri, Feb 5, 2021 at 7:45 AM Tony Lindgren  wrote:
>
> We can use iopoll for checking the EOCZ (end of conversion) bit. And with
> this we now also want to handle the timeout errors properly.
>
> For omap3, we need about 1.2ms for the single mode sampling to wait for
> EOCZ down, so let's use 1.5ms timeout there. Waiting for sampling to start
> is faster and we can use 1ms timeout.
>
> Cc: Adam Ford 
> Cc: Carl Philipp Klemm 
> Cc: Eduardo Valentin 
> Cc: H. Nikolaus Schaller 
> Cc: Merlijn Wajer 
> Cc: Pavel Machek 
> Cc: Peter Ujfalusi 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 

For the series,

Tested-by: Adam Ford  #logicpd-torpedo-37xx-devkit

> ---
>  drivers/thermal/ti-soc-thermal/ti-bandgap.c | 30 ++---
>  1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -27,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -604,7 +604,9 @@ static int
>  ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id)
>  {
> struct temp_sensor_registers *tsr = bgp->conf->sensors[id].registers;
> -   u32 counter;
> +   void __iomem *temp_sensor_ctrl = bgp->base + tsr->temp_sensor_ctrl;
> +   int error;
> +   u32 val;
>
> /* Select continuous or single conversion mode */
> if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
> @@ -619,26 +621,22 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, 
> int id)
> RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 1);
>
> /* Wait for EOCZ going up */
> -   counter = 1000;
> -   while (--counter) {
> -   if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> -   tsr->bgap_eocz_mask)
> -   break;
> -   udelay(1);
> -   }
> +   error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
> + val & tsr->bgap_eocz_mask,
> + 1, 1000);
> +   if (error)
> +   dev_warn(bgp->dev, "eocz timed out waiting high\n");
>
> /* Clear Start of Conversion if available */
> RMW_BITS(bgp, id, temp_sensor_ctrl, bgap_soc_mask, 0);
> }
>
> /* Wait for EOCZ going down, always needed even if no bgap_soc_mask */
> -   counter = 1000;
> -   while (--counter) {
> -   if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> - tsr->bgap_eocz_mask))
> -   break;
> -   udelay(1);
> -   }
> +   error = readl_poll_timeout_atomic(temp_sensor_ctrl, val,
> + !(val & tsr->bgap_eocz_mask),
> + 1, 1500);
> +   if (error)
> +   dev_warn(bgp->dev, "eocz timed out waiting low\n");
>
> return 0;
>  }
> --
> 2.30.0


RE: [PATCH v2] mfd: da9063: Support SMBus and I2C mode

2021-02-04 Thread Adam Thomson
On 04 February 2021 15:52, Mark Jonas wrote:

> From: Hubert Streidl 
> 
> By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> means the PMIC will automatically reset the interface when the clock
> signal ceases for more than the SMBus timeout of 35 ms.
> 
> If the I2C driver / device is not capable of creating atomic I2C
> transactions, a context change can cause a ceasing of the clock signal.
> This can happen if for example a real-time thread is scheduled. Then
> the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently
> a write message could end up in the wrong register. This could cause
> unpredictable system behavior.
> 
> The DA9063 PMIC also supports an I2C compliant mode for the 2-wire
> interface. This mode does not reset the interface when the clock
> signal ceases. Thus the problem depicted above does not occur.
> 
> This patch tests for the bus functionality "I2C_FUNC_I2C". It can
> reasonably be assumed that the bus cannot obey SMBus timings if
> this functionality is set. SMBus commands most probably are emulated
> in this case which is prone to the latency issue described above.
> 
> This patch enables the I2C bus mode if I2C_FUNC_I2C is set or
> otherwise enables the SMBus mode for a native SMBus controller
> which doesn't have I2C_FUNC_I2C set.
> 
> Signed-off-by: Hubert Streidl 
> Signed-off-by: Mark Jonas 
> ---
> Changes in v2:
>   - Implement proposal by Adam Thomson and Wolfram Sang to check for
> functionality I2C_FUNC_I2C instead of introducing a new DT property.
> 
>  drivers/mfd/da9063-i2c.c | 15 +++
>  include/linux/mfd/da9063/registers.h |  3 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
> index 3781d0bb7786..a2245253f039 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -355,6 +355,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>   const struct i2c_device_id *id)
>  {
>   struct da9063 *da9063;
> + unsigned int busmode;
>   int ret;
> 
>   da9063 = devm_kzalloc(>dev, sizeof(struct da9063), GFP_KERNEL);
> @@ -442,6 +443,20 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>   return ret;
>   }
> 
> + if (i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {
> + dev_info(da9063->dev, "I2C mode");
> + busmode = 0;
> + } else {
> + dev_info(da9063->dev, "SMBus mode");
> + busmode = 1;

I think this should be 'DA9063_TWOWIRE_TO' rather than '1' otherwise I think
you'll be setting 0 still here as it doesn't match up with the mask.

> + }
> + ret = regmap_update_bits(da9063->regmap, DA9063_REG_CONFIG_J,
> + DA9063_TWOWIRE_TO, busmode);
> + if (ret < 0) {
> + dev_err(da9063->dev, "Failed to set 2-wire bus mode.\n");
> + return -EIO;
> + }
> +
>   return da9063_device_init(da9063, i2c->irq);
>  }
> 
> diff --git a/include/linux/mfd/da9063/registers.h
> b/include/linux/mfd/da9063/registers.h
> index 1dbabf1b3cb8..6e0f66a2e727 100644
> --- a/include/linux/mfd/da9063/registers.h
> +++ b/include/linux/mfd/da9063/registers.h
> @@ -1037,6 +1037,9 @@
>  #define  DA9063_NONKEY_PIN_AUTODOWN  0x02
>  #define  DA9063_NONKEY_PIN_AUTOFLPRT 0x03
> 
> +/* DA9063_REG_CONFIG_J (addr=0x10F) */
> +#define DA9063_TWOWIRE_TO0x40
> +
>  /* DA9063_REG_MON_REG_5 (addr=0x116) */
>  #define DA9063_MON_A8_IDX_MASK   0x07
>  #define  DA9063_MON_A8_IDX_NONE  0x00
> --
> 2.25.1



Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-02-03 Thread Adam Ford
On Thu, Jan 21, 2021 at 4:24 AM Abel Vesa  wrote:
>
> On 21-01-21 10:56:17, Sascha Hauer wrote:
> > On Wed, Jan 20, 2021 at 06:14:21PM +0200, Abel Vesa wrote:
> > > On 21-01-20 16:50:01, Sascha Hauer wrote:
> > > > On Wed, Jan 20, 2021 at 05:28:13PM +0200, Abel Vesa wrote:
> > > > > On 21-01-20 16:13:05, Sascha Hauer wrote:
> > > > > > Hi Abel,
> > > > > >
> > > > > > On Wed, Jan 20, 2021 at 04:44:54PM +0200, Abel Vesa wrote:
> > > > > > > On 21-01-18 08:00:43, Adam Ford wrote:
> > > > > > > > On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa  
> > > > > > > > wrote:
> > > > >
> > > > > ...
> > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > TBH, I'm against the idea of having to call consumer API from 
> > > > > > > > > a clock provider driver.
> > > > > > > > > I'm still investigating a way of moving the uart clock 
> > > > > > > > > control calls in drivers/serial/imx,
> > > > > > > > > where they belong.
> > > > > > > >
> > > > > > > > That makes sense.
> > > > > > > >
> > > > > > >
> > > > > > > Just a thought. The uart clock used for console remains on from 
> > > > > > > u-boot,
> > > > > > > so maybe it's enough to just add the CLK_IGNORE_UNUSED flag to 
> > > > > > > all the
> > > > > > > uart root clocks and remove the prepare/enable calls for uart 
> > > > > > > clocks
> > > > > > > for good. I don't really have a way to test it right now, but 
> > > > > > > maybe
> > > > > > > you could give it a try.
> > > > > >
> > > > > > That would mean that UART clocks will never be disabled, regardless 
> > > > > > of
> > > > > > whether they are used for console or not. That doesn't sound very
> > > > > > appealing.
> > > > >
> > > > > AFAIK, the only uart clock that is enabled by u-boot is the one used 
> > > > > for
> > > > > the console. Later on, when the serial driver probes, it will enable 
> > > > > it itself.
> > > > >
> > > > > Unless I'm missing something, this is exactly what we need.
> > > >
> > > > It might enable it, but with CLK_IGNORE_UNUSED the clock won't be
> > > > disabled again when a port is closed after usage
> > >
> > > OK, tell me what I'm getting wrong in the following scenario:
> > >
> > > U-boot leaves the console uart clock enabled. All the other ones are 
> > > disabled.
> > >
> > > Kernel i.MX clk driver registers the uart clocks with flag 
> > > CLK_IGNORE_UNUSED.
> >
> > I was wrong at that point. I originally thought the kernel will never
> > disable these clocks, but in fact it only leaves them enabled during the
> > clk_disable_unused call.
> >
> > However, when CLK_IGNORE_UNUSED becomes relevant it's too late already.
> > I just chatted with Lucas and he told me what the original problem was
> > that his patch solved.
> >
> > The problem comes when an unrelated device and the earlycon UART have
> > the same parent clocks. The parent clock is enabled, but it's reference
> > count is zero. Now when the unrelated device probes and toggles its
> > clocks then the shared parent clock will be disabled due to the
> > reference count being zero. Next time earlycon prints a character the
> > system hangs because the UART gates are still enabled, but their parent
> > clocks no longer are.
> >
>
> Hmm, that is indeed a problem. That's why I think there should be some
> kind of NOCACHE flag for almost all the types of clocks. For example,
> in this case, it makes sense for the core to check the bit in the register
> and then disable the parent based on that instead of relying on the refcount.
> Anyway, that's something that needs to be added in the CCF.
>
> > Overall I think Lucas' patches are still valid and relevant and with
> > Adams patches we even no longer have to enable all UART clocks, but
> > only the ones which are actually needed.
>
> Yeah, for now, I think we can go with Adam's patches. But longterm, I would
> like to remove the special case of the uart clocks we have right now in all
> the i.MX clock drivers.
>

Is the patch I submitted good enough for someone's acked-by or
reviewed-by, or are there changes I need to implement?

adam

> >
> > Sascha
> >
> >
> > --
> > Pengutronix e.K.   | |
> > Steuerwalder Str. 21   | 
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2Fdata=04%7C01%7Cabel.vesa%40nxp.com%7Ceed68987c68f4aeaa63408d8bdf2d051%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637468197861821302%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X1J8KgxFquNin80zKVz0Ao22vv1MuTMWf91BUTczh9Y%3Dreserved=0
> >   |
> > 31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
> > Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


RE: [PATCH 1/1] mfd: da9063: Support SMBus and I2C mode

2021-01-28 Thread Adam Thomson
On 25 January 2021 12:55, Mark Jonas wrote:

> From: Hubert Streidl 
> 
> By default the PMIC DA9063 2-wire interface is SMBus compliant. This
> means the PMIC will automatically reset the interface when the clock
> signal ceases for more than the SMBus timeout of 35 ms.
> 
> If the I2C driver / device is not capable of creating atomic I2C
> transactions, a context change can cause a ceasing of the the clock
> signal. This can happen if for example a real-time thread is scheduled.
> Then the DA9063 in SMBus mode will reset the 2-wire interface.
> Subsequently a write message could end up in the wrong register. This
> could cause unpredictable system behavior.
> 
> The DA9063 PMIC also supports an I2C compliant mode for the 2-wire
> interface. This mode does not reset the interface when the clock
> signal ceases. Thus the problem depicted above does not occur.
> 
> This patch makes the I2C mode configurable by device tree. The SMBus
> compliant mode is kept as the default.

Could we not just check the bus' functionality flags and set this accordingly?
Something like this is already done in regmap-i2c to determine how to access 
the device:

 
https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-i2c.c#L309

This seems cleaner than a new DT property, or will this not work in this
situation?

> 
> Signed-off-by: Hubert Streidl 
> Signed-off-by: Mark Jonas 
> ---
>  Documentation/devicetree/bindings/mfd/da9063.txt |  7 +++
>  drivers/mfd/da9063-core.c|  9 +
>  drivers/mfd/da9063-i2c.c | 13 +
>  include/linux/mfd/da9063/core.h  |  1 +
>  include/linux/mfd/da9063/registers.h |  3 +++
>  5 files changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt
> b/Documentation/devicetree/bindings/mfd/da9063.txt
> index 8da879935c59..256f2a25fe0a 100644
> --- a/Documentation/devicetree/bindings/mfd/da9063.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9063.txt
> @@ -19,6 +19,12 @@ Required properties:
>  - interrupts : IRQ line information.
>  - interrupt-controller
> 
> +Optional properties:
> +
> +- i2c-mode : Switch serial 2-wire interface into I2C mode. Without this
> +  property the PMIC uses the SMBus mode (resets the interface if the clock
> +  ceases for a longer time than the SMBus timeout).
> +
>  Sub-nodes:
> 
>  - regulators : This node defines the settings for the LDOs and BUCKs.
> @@ -77,6 +83,7 @@ Example:
>   interrupt-parent = <>;
>   interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
>   interrupt-controller;
> + i2c-mode;
> 
>   rtc {
>   compatible = "dlg,da9063-rtc";
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
> index df407c3afce3..baa1e4310c8c 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -162,6 +162,15 @@ int da9063_device_init(struct da9063 *da9063, unsigned
> int irq)
>  {
>   int ret;
> 
> + if (da9063->i2cmode) {
> + ret = regmap_update_bits(da9063->regmap,
> DA9063_REG_CONFIG_J,
> + DA9063_TWOWIRE_TO, 0);
> + if (ret < 0) {
> + dev_err(da9063->dev, "Cannot enable I2C mode.\n");
> + return -EIO;
> + }
> + }
> +
>   ret = da9063_clear_fault_log(da9063);
>   if (ret < 0)
>   dev_err(da9063->dev, "Cannot clear fault log\n");
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
> index 3781d0bb7786..af0bf13ab43e 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -351,6 +351,17 @@ static const struct of_device_id da9063_dt_ids[] = {
>   { }
>  };
>  MODULE_DEVICE_TABLE(of, da9063_dt_ids);
> +
> +static void da9063_i2c_parse_dt(struct i2c_client *client, struct da9063 
> *da9063)
> +{
> + struct device_node *np = client->dev.of_node;
> +
> + if (of_property_read_bool(np, "i2c-mode"))
> + da9063->i2cmode = true;
> + else
> + da9063->i2cmode = false;
> +}
> +
>  static int da9063_i2c_probe(struct i2c_client *i2c,
>   const struct i2c_device_id *id)
>  {
> @@ -366,6 +377,8 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>   da9063->chip_irq = i2c->irq;
>   da9063->type = id->driver_data;
> 
> + da9063_i2c_parse_dt(i2c, da9063);
> +
>   ret = da9063_get_device_type(i2c, da9063);
>   if (ret)
>   return ret;
> diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
> index fa7a43f02f27..866864c50f78 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -77,6 +77,7 @@ struct da9063 {
>   enum da9063_type type;
>   unsigned char   variant_code;
>   unsigned intflags;
> + booli2cmode;
> 
>   /* Control interface */
>   struct regmap   *regmap;
> diff --git 

Re: 5.10 LTS Kernel: 2 or 6 years?

2021-01-26 Thread Adam Borowski
On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:
> The 5.10 LTS kernel being officially LTS supported for 2 years presents a 
> problem:
> why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has a 6 
> year LTS.
> 
> Yet, various unofficial reports indicate it will be supported for 6
> years.  And AOSP has already declared the use of 5.10 kernel in their
> Android S and T releases.

5.10 will also be used for Debian Bullseye.

-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `


Re: [PATCH V2 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-01-20 Thread Adam Ford
On Wed, Jan 20, 2021 at 10:35 AM Luca Ceresoli  wrote:
>
> Hi Adam,
>
> On 19/01/21 22:21, Adam Ford wrote:
> > There are two registers which can set the load capacitance for
> > XTAL1 and XTAL2. These are optional registers when using an
> > external crystal.  Since XTAL1 and XTAL2 will set to the same value,
> > update the binding to support a single property called
> > xtal-load-femtofarads.
> >
> > Signed-off-by: Adam Ford 
> > ---
> > V2:  No Change
> >
> > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > index 2ac1131fd922..c268debe5b8d 100644
> > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > @@ -59,6 +59,12 @@ properties:
> >  minItems: 1
> >  maxItems: 2
> >
> > +  idt,xtal-load-femtofarads:
> > +$ref: /schemas/types.yaml#/definitions/uint32
>
> "Vendor specific properties having a standard unit suffix don't need a
> type." -- Documentation/devicetree/bindings/example-schema.yaml
>

I tried to remove the "$ref: /schemas/types.yaml#/definitions/uint32"
but when I ran the test to make the yaml files, it threw an error, so
I put it back.

adam
> Overall looks good.
>
> --
> Luca


[PATCH 1/2] arm64: dts: imx8mn: Add fspi node

2021-01-19 Thread Adam Ford
The i.MX8M Nano has the same Flexspi controller used in the i.MX8M
Mini.  Add the node and disable it by default.

Signed-off-by: Adam Ford 

diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 3fac73779fdd..16ea50089567 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -889,6 +889,19 @@ usdhc3: mmc@30b6 {
status = "disabled";
};
 
+   flexspi: spi@30bb {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "nxp,imx8mm-fspi";
+   reg = <0x30bb 0x1>, <0x800 
0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   interrupts = ;
+   clocks = < IMX8MN_CLK_QSPI_ROOT>,
+< IMX8MN_CLK_QSPI_ROOT>;
+   clock-names = "fspi", "fspi_en";
+   status = "disabled";
+   };
+
sdma1: dma-controller@30bd {
compatible = "fsl,imx8mn-sdma", 
"fsl,imx8mq-sdma";
reg = <0x30bd 0x1>;
-- 
2.25.1



[PATCH 2/2] arm64: dts: imx8mn-beacon-som: Enable QSPI on SOM

2021-01-19 Thread Adam Ford
There is a QSPI chip connected to the FlexSPI bus.  Enable it.

Signed-off-by: Adam Ford 

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index 2120e6485393..9f575184d899 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -7,6 +7,7 @@ / {
aliases {
rtc0 = 
rtc1 = _rtc;
+   spi0 = 
};
 
usdhc1_pwrseq: usdhc1_pwrseq {
@@ -89,6 +90,22 @@ ethphy0: ethernet-phy@0 {
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_flexspi>;
+   status = "okay";
+
+   flash@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <8000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+};
+
  {
clock-frequency = <40>;
pinctrl-names = "default";
@@ -318,6 +335,18 @@ MX8MN_IOMUXC_I2C3_SDA_I2C3_SDA 0x41c3
>;
};
 
+   pinctrl_flexspi: flexspigrp {
+   fsl,pins = <
+   MX8MN_IOMUXC_NAND_ALE_QSPI_A_SCLK   0x1c2
+   MX8MN_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B0x82
+   MX8MN_IOMUXC_NAND_DATA00_QSPI_A_DATA0   0x82
+   MX8MN_IOMUXC_NAND_DATA01_QSPI_A_DATA1   0x82
+   MX8MN_IOMUXC_NAND_DATA02_QSPI_A_DATA2   0x82
+   MX8MN_IOMUXC_NAND_DATA03_QSPI_A_DATA3   0x82
+   >;
+   };
+
+
pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3   0x141
-- 
2.25.1



[PATCH V2 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-01-19 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Since XTAL1 and XTAL2 will set to the same value,
update the binding to support a single property called
xtal-load-femtofarads.

Signed-off-by: Adam Ford 
---
V2:  No Change

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
index 2ac1131fd922..c268debe5b8d 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
@@ -59,6 +59,12 @@ properties:
 minItems: 1
 maxItems: 2
 
+  idt,xtal-load-femtofarads:
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 9000
+maximum: 22760
+description: Optional load capacitor for XTAL1 and XTAL2
+
 patternProperties:
   "^OUT[1-4]$":
 type: object
-- 
2.25.1



[PATCH V2 2/2] clk: vc5: Add support for optional load capacitance

2021-01-19 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Parse the device tree and set the
corresponding registers accordingly.

Signed-off-by: Adam Ford 
---
V2:  Make the math subtract 9000 since we have a DIV_ROUND_CLOSEST
 This also allows us to remove the check for 9430 since values
 between 9000 and 9430 will round up and down.
 Make write VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP
 a read-modify-write to not worry about the contents of
 bits[1:0].

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..c6b04c077224 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,74 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
 }
 
+static int vc5_map_cap_value(u32 femtofarads)
+{
+   int mapped_value;
+
+   /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+   if (femtofarads < 9000 || femtofarads > 22760)
+   return -EINVAL;
+
+   /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange.  With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+
+   mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9000, 430);
+
+   /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32.  In reality, this means
+* the real mapped value should be 11b.  In other clases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+
+   if (mapped_value > 31)
+   mapped_value = 0x3f;
+   else
+   mapped_value <<= 1;
+
+   return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct 
vc5_driver_data *vc5)
+{
+   u32 value;
+   int mapped_value, cache;
+
+   if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+   mapped_value = vc5_map_cap_value(value);
+   if (mapped_value < 0)
+   return mapped_value;
+
+   /*
+* The mapped_value is really the high 6 bits of
+* VC5_XTAL_X1_LOAD_CAP and VC5_XTAL_X2_LOAD_CAP, so
+* shift the value 2 places.  Read each register, wipe out
+* the top 6 bits and, write the combined data back.
+*/
+
+   mapped_value = (mapped_value << 2);
+
+   cache = regmap_read(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, );
+   cache &= 0x03;
+   regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value | 
cache);
+
+   cache = regmap_read(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, );
+   cache &= 0x03;
+   regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value | 
cache);
+   }
+
+   return 0;
+}
+
 static int vc5_update_slew(struct device_node *np_output,
   struct vc5_out_data *clk_out)
 {
@@ -884,6 +952,13 @@ static int vc5_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return -EINVAL;
}
 
+   /* Configure Optional Loading Capacitance for external XTAL */
+   if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+   ret = vc5_update_cap_load(client->dev.of_node, vc5);
+   if (ret)
+   goto err_clk_register;
+   }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
-- 
2.25.1



Re: [PATCH 2/2] clk: vc5: Add support for optional load capacitance

2021-01-18 Thread Adam Ford
On Sat, Jan 16, 2021 at 3:55 PM Adam Ford  wrote:
>
> There are two registers which can set the load capacitance for
> XTAL1 and XTAL2. These are optional registers when using an
> external crystal.  Parse the device tree and set the
> corresponding registers accordingly.
>
> Signed-off-by: Adam Ford 
>
> diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> index 43db67337bc0..224118ca08fd 100644
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -759,6 +759,72 @@ static int vc5_update_power(struct device_node 
> *np_output,
> return 0;
>  }
>
> +static int vc5_map_cap_value(u32 femtofarads)
> +{
> +   int mapped_value;
> +
> +   /*
> +* The datasheet explicitly states 9000 - 25000 with 0.5pF
> +* steps, but the Programmer's guide shows the steps are 0.430pF.
> +* After getting feedback from Renesas, the .5pF steps were the
> +* goal, but 430nF was the actual values.
> +* Because of this, the actual range goes to 22760 instead of 25000
> +*/
> +   if (femtofarads < 9000 || femtofarads > 22760)
> +   return -EINVAL;
> +
> +   /* The lowest target we can hit is 9430, so exit if it's less */
> +   if (femtofarads < 9430)
> +   return 0;
> +
> +   /*
> +* The Programmer's guide shows XTAL[5:0] but in reality,
> +* XTAL[0] and XTAL[1] are both LSB which makes the math
> +* strange.  With clarfication from Renesas, setting the
> +* values should be simpler by ignoring XTAL[0]
> +*/
> +
> +   mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9430, 430);
> +
> +   /*
> +* Since the calculation ignores XTAL[0], there is one
> +* special case where mapped_value = 32.  In reality, this means
> +* the real mapped value should be 11b.  In other clases,
> +* the mapped_value needs to be shifted 1 to the left.
> +*/
> +
> +   if (mapped_value > 31)
> +   mapped_value = 0x3f;
> +   else
> +   mapped_value <<= 1;
> +
> +   return mapped_value;
> +}
> +static int vc5_update_cap_load(struct device_node *node, struct 
> vc5_driver_data *vc5)
> +{
> +   u32 value;
> +   int mapped_value;
> +
> +   if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) 
> {
> +   mapped_value = vc5_map_cap_value(value);
> +   if (mapped_value < 0)
> +   return mapped_value;
> +
> +   /*
> +* According to Renesas, bits [1:0] of VC5_XTAL_X1_LOAD_CAP
> +* and VC5_XTAL_X2_LOAD_CAP should always be 01b.
> +* Since the mapped_value is really the high 6 bits of 8,
> +* shift the value 2 places and or in the 0x01;
> +*/
> +
> +   mapped_value = (mapped_value << 2) | 0x01;
> +   regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value);
> +   regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value);

On second thought I'm going to change register write to a
read-modify-write since the low two bits are unclear and X1 and X2 low
bits are not exactly the same.   Since the info is confusing, I can
cache VC5_XTAL_X1_LOAD_CAP, clear the upper 6 bits and then logic-or
the value.  This way we don't have to guess about what the 0x01.  It
also appears the 0x01 is only for one of the registers and not both.


> +   }
> +
> +   return 0;
> +}
> +
>  static int vc5_update_slew(struct device_node *np_output,
>struct vc5_out_data *clk_out)
>  {
> @@ -884,6 +950,13 @@ static int vc5_probe(struct i2c_client *client, const 
> struct i2c_device_id *id)
> return -EINVAL;
> }
>
> +   /* Configure Optional Loading Capacitance for external XTAL */
> +   if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
> +   ret = vc5_update_cap_load(client->dev.of_node, vc5);
> +   if (ret)
> +   goto err_clk_register;
> +   }
> +
> init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
> init.ops = _mux_ops;
> init.flags = 0;
> --
> 2.25.1
>


Re: [PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-01-18 Thread Adam Ford
On Mon, Jan 18, 2021 at 6:52 AM Abel Vesa  wrote:
>
> On 21-01-15 12:29:08, Adam Ford wrote:
>
> ...
>
> > diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
> > index a66cabfbf94f..66192fe0a898 100644
> > --- a/drivers/clk/imx/clk-imx25.c
> > +++ b/drivers/clk/imx/clk-imx25.c
> > @@ -73,16 +73,6 @@ enum mx25_clks {
> >
> >  static struct clk *clk[clk_max];
> >
> > -static struct clk ** const uart_clks[] __initconst = {
> > - [uart_ipg_per],
> > - [uart1_ipg],
> > - [uart2_ipg],
> > - [uart3_ipg],
> > - [uart4_ipg],
> > - [uart5_ipg],
> > - NULL
> > -};
> > -
>
> I'm assuming there is another patch that updates the dts files. Right ?

I have only been able to test this on an i.MX8M Mini.  I need to set
the parent clock of the i.MX8M Mini to an 80 MHz clock in order to run
the UART at 4Mbps.   With this patch, I can stop enabling the all the
UART clocks early and allow the clock parent configuration to occur.
>From what I can tell, the remaining clocks should get activated as
they are needed, because I was able to use Bluetooth connected to
UART1 running at 4MBps using a 80MHz clock source with this patch, and
the clk_summary shows the clock is running at the proper speed.
Without this patch, the UART fails to re-parent, so I'm stuck at lower
speeds and that means choppy Bluetooth audio.

The Kernel that NXP hosts on Code Aurora that they use for Yocto
attempts scan through stdout to only enable those clocks [1].  I
attempted to push it upstream, but it was rejected [2].  Sascha
suggested creating an array which could be filled when the clocks are
enabled and that array would be used to deactivate the clocks at
shutdown.  That's what I attempted to do here.

I don't have older imx boards to know if their device trees are
configured in such a way without modifications to the device tree or
not, but since it appears to work for NXP in [2], I assumed it would
work here.

[1] - 
https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/clk/imx/clk.c?h=imx_5.4.47_2.2.0=754ae82cc55b7445545fc2f092a70e0f490e9c1b
[2] - 
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201229145130.2680442-1-aford...@gmail.com/

>
> TBH, I'm against the idea of having to call consumer API from a clock 
> provider driver.
> I'm still investigating a way of moving the uart clock control calls in 
> drivers/serial/imx,
> where they belong.

That makes sense.

>
> >  static int __init __mx25_clocks_init(void __iomem *ccm_base)
> >  {
> >   BUG_ON(!ccm_base);
> > @@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem 
> > *ccm_base)
> >*/
> >   clk_set_parent(clk[cko_sel], clk[ipg]);
> >
> > - imx_register_uart_clocks(uart_clks);
> > + imx_register_uart_clocks(6);
>
> Suggestion: Maybe the number of clocks can be determined by the existing 
> clocks in that dts node.
> Hardcoding is not a good ideea here.

The tables were hard-coded before, so the idea was to pass the maximum
number of clocks instead the entire table.  The higher-level clock
code wouldn't necessarily know the maximum number of UART clocks since
the number of UARTs may change depending on the SoC.  So that
hard-coded number was simply the number of entries that were
previously used in the array that was previously passed.  When
creating a table of active clocks, it could use the number passed to
define an array, and fill the array with data grabbed from of_stdout.

If you want, I could leave the existing UART clocks alone, and create
a new function that uses the array of clocks passed to it to count the
number of available clocks.  It would limit the scope of the change to
clk/imx/clk.c.  I think that would be easier than trying to parse the
DT for a bunch of compatible flags looking for a bunch of UARTS and
their respective clocks.

If you'd rather do something in the serial imx driver, I can hold off.

adam
>
> ...
>
> >
> > diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
> > index 47882c51cb85..158fe302a8b7 100644
> > --- a/drivers/clk/imx/clk.c
> > +++ b/drivers/clk/imx/clk.c
> > @@ -147,8 +147,10 @@ void imx_cscmr1_fixup(u32 *val)
> >  }
> >
> >  #ifndef MODULE
> > -static int imx_keep_uart_clocks;
> > -static struct clk ** const *imx_uart_clocks;
> > +
> > +static bool imx_keep_uart_clocks;
> > +static int imx_enabled_uart_clocks;
> > +static struct clk **imx_uart_clocks;
> >
> >  static int __init imx_keep_uart_clocks_param(char *str)
> >  {
> > @@ -161,24 +163,43 @@ __setup_param("earlycon", imx_keep_uart_earlycon,
> >  __setup_param("earlyprintk", imx_keep_uart_ea

[PATCH 2/2] clk: vc5: Add support for optional load capacitance

2021-01-16 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Parse the device tree and set the
corresponding registers accordingly.

Signed-off-by: Adam Ford 

diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 43db67337bc0..224118ca08fd 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -759,6 +759,72 @@ static int vc5_update_power(struct device_node *np_output,
return 0;
 }
 
+static int vc5_map_cap_value(u32 femtofarads)
+{
+   int mapped_value;
+
+   /*
+* The datasheet explicitly states 9000 - 25000 with 0.5pF
+* steps, but the Programmer's guide shows the steps are 0.430pF.
+* After getting feedback from Renesas, the .5pF steps were the
+* goal, but 430nF was the actual values.
+* Because of this, the actual range goes to 22760 instead of 25000
+*/
+   if (femtofarads < 9000 || femtofarads > 22760)
+   return -EINVAL;
+
+   /* The lowest target we can hit is 9430, so exit if it's less */
+   if (femtofarads < 9430)
+   return 0;
+
+   /*
+* The Programmer's guide shows XTAL[5:0] but in reality,
+* XTAL[0] and XTAL[1] are both LSB which makes the math
+* strange.  With clarfication from Renesas, setting the
+* values should be simpler by ignoring XTAL[0]
+*/
+
+   mapped_value = DIV_ROUND_CLOSEST(femtofarads - 9430, 430);
+
+   /*
+* Since the calculation ignores XTAL[0], there is one
+* special case where mapped_value = 32.  In reality, this means
+* the real mapped value should be 11b.  In other clases,
+* the mapped_value needs to be shifted 1 to the left.
+*/
+
+   if (mapped_value > 31)
+   mapped_value = 0x3f;
+   else
+   mapped_value <<= 1;
+
+   return mapped_value;
+}
+static int vc5_update_cap_load(struct device_node *node, struct 
vc5_driver_data *vc5)
+{
+   u32 value;
+   int mapped_value;
+
+   if (!of_property_read_u32(node, "idt,xtal-load-femtofarads", )) {
+   mapped_value = vc5_map_cap_value(value);
+   if (mapped_value < 0)
+   return mapped_value;
+
+   /*
+* According to Renesas, bits [1:0] of VC5_XTAL_X1_LOAD_CAP
+* and VC5_XTAL_X2_LOAD_CAP should always be 01b.
+* Since the mapped_value is really the high 6 bits of 8,
+* shift the value 2 places and or in the 0x01;
+*/
+
+   mapped_value = (mapped_value << 2) | 0x01;
+   regmap_write(vc5->regmap, VC5_XTAL_X1_LOAD_CAP, mapped_value);
+   regmap_write(vc5->regmap, VC5_XTAL_X2_LOAD_CAP, mapped_value);
+   }
+
+   return 0;
+}
+
 static int vc5_update_slew(struct device_node *np_output,
   struct vc5_out_data *clk_out)
 {
@@ -884,6 +950,13 @@ static int vc5_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return -EINVAL;
}
 
+   /* Configure Optional Loading Capacitance for external XTAL */
+   if (!(vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)) {
+   ret = vc5_update_cap_load(client->dev.of_node, vc5);
+   if (ret)
+   goto err_clk_register;
+   }
+
init.name = kasprintf(GFP_KERNEL, "%pOFn.mux", client->dev.of_node);
init.ops = _mux_ops;
init.flags = 0;
-- 
2.25.1



[PATCH 1/2] dt-bindings: clk: versaclock5: Add optional load capacitance property

2021-01-16 Thread Adam Ford
There are two registers which can set the load capacitance for
XTAL1 and XTAL2. These are optional registers when using an
external crystal.  Since XTAL1 and XTAL2 will set to the same value,
update the binding to support a single property called
xtal-load-femtofarads.

Signed-off-by: Adam Ford 

diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
index 2ac1131fd922..c268debe5b8d 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
@@ -59,6 +59,12 @@ properties:
 minItems: 1
 maxItems: 2
 
+  idt,xtal-load-femtofarads:
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 9000
+maximum: 22760
+description: Optional load capacitor for XTAL1 and XTAL2
+
 patternProperties:
   "^OUT[1-4]$":
 type: object
-- 
2.25.1



[PATCH V2 3/4] arm64: dts: renesas: Add fck to etheravb-rcar-gen3 clock-names list

2021-01-15 Thread Adam Ford
The bindings have been updated to support two clocks, but the
original clock now requires the name fck.  Add a clock-names
list in the device tree with fck in it.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77951.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77960.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77961.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77970.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77980.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 1 +
 arch/arm64/boot/dts/renesas/r8a77995.dtsi | 1 +
 12 files changed, 12 insertions(+)

V2:  No change

diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index d64fb8b1b86c..ec4feb7df775 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1127,6 +1127,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774A1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index 5b05474dc272..1ff62b2be1f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -1001,6 +1001,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774B1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index 20fa3caa050e..a4d9c6b31574 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -957,6 +957,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774C0_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi 
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index 8eb006cbd9af..fec5839163ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -1230,6 +1230,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A774E1_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index 5c39152e4570..1e622ab8a044 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -1312,6 +1312,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
  "ch24";
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 812>;
phy-mode = "rgmii";
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi 
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 25d947a81b29..a3d1c33cbc1d 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -1188,6 +1188,7 @@ avb: ethernet@e680 {
  "ch20", "ch21", "ch22", "ch23",
   

[PATCH V2 1/4] dt-bindings: net: renesas,etheravb: Add additional clocks

2021-01-15 Thread Adam Ford
The AVB driver assumes there is an external crystal, but it could
be clocked by other means.  In order to enable a programmable
clock, it needs to be added to the clocks list and enabled in the
driver.  Since there currently only one clock, there is no
clock-names list either.

Update bindings to add the additional optional clock, and explicitly
name both of them.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/net/renesas,etheravb.yaml | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

V2:  Change name from TXC Refclock to refclock
 The r-b and a-b notes were pulled from patchwork.

diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml 
b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
index 244befb6402a..9f84d9c6f141 100644
--- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml
@@ -49,7 +49,16 @@ properties:
   interrupt-names: true
 
   clocks:
-maxItems: 1
+minItems: 1
+maxItems: 2
+items:
+  - description: AVB functional clock
+  - description: Optional reference clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: refclk
 
   iommus:
 maxItems: 1
-- 
2.25.1



[PATCH V2 4/4] net: ethernet: ravb: Enable optional refclk

2021-01-15 Thread Adam Ford
For devices that use a programmable clock for the avb reference clock,
the driver may need to enable them.  Add code to find the optional clock
and enable it when available.

Signed-off-by: Adam Ford 
---
 drivers/net/ethernet/renesas/ravb.h  | 1 +
 drivers/net/ethernet/renesas/ravb_main.c | 8 
 2 files changed, 9 insertions(+)

V2:  The previous patch to fetch the fclk was dropped.  In its place
 is code to enable the refclk

diff --git a/drivers/net/ethernet/renesas/ravb.h 
b/drivers/net/ethernet/renesas/ravb.h
index 7453b17a37a2..ff363797bd2b 100644
--- a/drivers/net/ethernet/renesas/ravb.h
+++ b/drivers/net/ethernet/renesas/ravb.h
@@ -994,6 +994,7 @@ struct ravb_private {
struct platform_device *pdev;
void __iomem *addr;
struct clk *clk;
+   struct clk *refclk;
struct mdiobb_ctrl mdiobb;
u32 num_rx_ring[NUM_RX_QUEUE];
u32 num_tx_ring[NUM_TX_QUEUE];
diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index bd30505fbc57..739e30f45daa 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2148,6 +2148,14 @@ static int ravb_probe(struct platform_device *pdev)
goto out_release;
}
 
+   priv->refclk = devm_clk_get_optional(>dev, "refclk");
+   if (IS_ERR(priv->refclk)) {
+   error = PTR_ERR(priv->refclk);
+   goto out_release;
+   } else {
+   (void)clk_prepare_enable(priv->refclk);
+   }
+
ndev->max_mtu = 2048 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
 
-- 
2.25.1



[PATCH V2 2/4] ARM: dts: renesas: Add fck to etheravb-rcar-gen2 clock-names list

2021-01-15 Thread Adam Ford
The bindings have been updated to support two clocks, but the
original clock now requires the name fck.  Add a clock-names
list in the device tree with fck in it.

Signed-off-by: Adam Ford 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/r8a7742.dtsi  | 1 +
 arch/arm/boot/dts/r8a7743.dtsi  | 1 +
 arch/arm/boot/dts/r8a7744.dtsi  | 1 +
 arch/arm/boot/dts/r8a7745.dtsi  | 1 +
 arch/arm/boot/dts/r8a77470.dtsi | 1 +
 arch/arm/boot/dts/r8a7790.dtsi  | 1 +
 arch/arm/boot/dts/r8a7791.dtsi  | 1 +
 arch/arm/boot/dts/r8a7792.dtsi  | 1 +
 arch/arm/boot/dts/r8a7794.dtsi  | 1 +
 9 files changed, 9 insertions(+)

V2:  No change

diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
index 6a78c813057b..6b922f664fcd 100644
--- a/arch/arm/boot/dts/r8a7742.dtsi
+++ b/arch/arm/boot/dts/r8a7742.dtsi
@@ -750,6 +750,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7742_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index f444e418f408..084bf3e039cf 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7743_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index 0442aad4f9db..d01eba99ceb0 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -702,6 +702,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7744_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0f14ac22921d..d0d45a369047 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -645,6 +645,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7745_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index 691b1a131c87..ae90a001d663 100644
--- a/arch/arm/boot/dts/r8a77470.dtsi
+++ b/arch/arm/boot/dts/r8a77470.dtsi
@@ -537,6 +537,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A77470_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b0569b4ea5c8..af9cd3324f4c 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -768,6 +768,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";
power-domains = < R8A7790_PD_ALWAYS_ON>;
resets = < 812>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 87f0d6dc3e5a..2354af7fa83f 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -728,6 +728,7 @@ avb: ethernet@e680 {
reg = <0 0xe680 0 0x800>, <0 0xee0e8000 0 0x4000>;
interrupts = ;
clocks = < CPG_MOD 812>;
+   clock-names = "fck";

[PATCH V3] clk: imx: Fix reparenting of UARTs not associated with sdout

2021-01-15 Thread Adam Ford
Most if not all i.MX SoC's call a function which enables all UARTS.
This is a problem for users who need to re-parent the clock source,
because any attempt to change the parent results in an busy error
due to the fact that the clocks have been enabled already.

  clk: failed to reparent uart1 to sys_pll1_80m: -16

Instead of pre-initializing all UARTS, scan the device tree to see
which UART clocks are associated to stdout, and only enable those
UART clocks if it's needed early.  This will move initialization of
the remaining clocks until after the parenting of the clocks.

When the clocks are shutdown, this mechanism will also disable any
clocks that were pre-initialized.

Fixes: 9461f7b33d11c ("clk: fix CLK_SET_RATE_GATE with clock rate protection")
Suggested-by: Aisheng Dong 
Signed-off-by: Adam Ford 
---
V3:  Return a method more closely related to upstream kernel but
 instead of passing an array of UART's, each SoC passes the max
 number of UART clocks is has.  The imx clock driver will create
 an array to enable on startup, and disable later.
V2:  Attempt to port driver from vendor kernel.

diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
index a66cabfbf94f..66192fe0a898 100644
--- a/drivers/clk/imx/clk-imx25.c
+++ b/drivers/clk/imx/clk-imx25.c
@@ -73,16 +73,6 @@ enum mx25_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [uart_ipg_per],
-   [uart1_ipg],
-   [uart2_ipg],
-   [uart3_ipg],
-   [uart4_ipg],
-   [uart5_ipg],
-   NULL
-};
-
 static int __init __mx25_clocks_init(void __iomem *ccm_base)
 {
BUG_ON(!ccm_base);
@@ -228,7 +218,7 @@ static int __init __mx25_clocks_init(void __iomem *ccm_base)
 */
clk_set_parent(clk[cko_sel], clk[ipg]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(6);
 
return 0;
 }
diff --git a/drivers/clk/imx/clk-imx27.c b/drivers/clk/imx/clk-imx27.c
index 5585ded8b8c6..56a5fc402b10 100644
--- a/drivers/clk/imx/clk-imx27.c
+++ b/drivers/clk/imx/clk-imx27.c
@@ -49,17 +49,6 @@ static const char *ssi_sel_clks[] = { "spll_gate", "mpll", };
 static struct clk *clk[IMX27_CLK_MAX];
 static struct clk_onecell_data clk_data;
 
-static struct clk ** const uart_clks[] __initconst = {
-   [IMX27_CLK_PER1_GATE],
-   [IMX27_CLK_UART1_IPG_GATE],
-   [IMX27_CLK_UART2_IPG_GATE],
-   [IMX27_CLK_UART3_IPG_GATE],
-   [IMX27_CLK_UART4_IPG_GATE],
-   [IMX27_CLK_UART5_IPG_GATE],
-   [IMX27_CLK_UART6_IPG_GATE],
-   NULL
-};
-
 static void __init _mx27_clocks_init(unsigned long fref)
 {
BUG_ON(!ccm);
@@ -176,7 +165,7 @@ static void __init _mx27_clocks_init(unsigned long fref)
 
clk_prepare_enable(clk[IMX27_CLK_EMI_AHB_GATE]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(7);
 
imx_print_silicon_rev("i.MX27", mx27_revision());
 }
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 7b13fb57d842..c44e18c6f63f 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -51,16 +51,6 @@ enum mx31_clks {
 static struct clk *clk[clk_max];
 static struct clk_onecell_data clk_data;
 
-static struct clk ** const uart_clks[] __initconst = {
-   [ipg],
-   [uart1_gate],
-   [uart2_gate],
-   [uart3_gate],
-   [uart4_gate],
-   [uart5_gate],
-   NULL
-};
-
 static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
 {
clk[dummy] = imx_clk_fixed("dummy", 0);
diff --git a/drivers/clk/imx/clk-imx35.c b/drivers/clk/imx/clk-imx35.c
index c1df03665c09..0fe5ac210156 100644
--- a/drivers/clk/imx/clk-imx35.c
+++ b/drivers/clk/imx/clk-imx35.c
@@ -82,14 +82,6 @@ enum mx35_clks {
 
 static struct clk *clk[clk_max];
 
-static struct clk ** const uart_clks[] __initconst = {
-   [ipg],
-   [uart1_gate],
-   [uart2_gate],
-   [uart3_gate],
-   NULL
-};
-
 static void __init _mx35_clocks_init(void)
 {
void __iomem *base;
@@ -243,7 +235,7 @@ static void __init _mx35_clocks_init(void)
 */
clk_prepare_enable(clk[scc_gate]);
 
-   imx_register_uart_clocks(uart_clks);
+   imx_register_uart_clocks(4);
 
imx_print_silicon_rev("i.MX35", mx35_revision());
 }
diff --git a/drivers/clk/imx/clk-imx5.c b/drivers/clk/imx/clk-imx5.c
index 01e079b81026..e4493846454d 100644
--- a/drivers/clk/imx/clk-imx5.c
+++ b/drivers/clk/imx/clk-imx5.c
@@ -128,30 +128,6 @@ static const char *ieee1588_sels[] = { "pll3_sw", 
"pll4_sw", "dummy" /* usbphy2_
 static struct clk *clk[IMX5_CLK_END];
 static struct clk_onecell_data clk_data;
 
-static struct clk ** const uart_clks_mx51[] __initconst = {
-   [IMX5_CLK_UART1_IPG_GATE],
-   [IMX5_CLK_UART1_PER_GATE],
-   [IMX5_CLK_UART2_IPG_GATE],
-   [IMX5_CLK_UART2_PER_GATE],
-   [IMX5_CLK

Re: [RFC 1/2] dt-bindings: clk: versaclock5: Add load capacitance properties

2021-01-13 Thread Adam Ford
On Tue, Jan 12, 2021 at 9:16 PM Rob Herring  wrote:
>
> On Wed, Jan 06, 2021 at 11:38:59AM -0600, Adam Ford wrote:
> > There are two registers which can set the load capacitance for
> > XTAL1 and XTAL2. These are optional registers when using an
> > external crystal.  Update the bindings to support them.
> >
> > Signed-off-by: Adam Ford 
> > ---
> >  .../devicetree/bindings/clock/idt,versaclock5.yaml   | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> > b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > index 2ac1131fd922..e5e55ffb266e 100644
> > --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> > @@ -59,6 +59,18 @@ properties:
> >  minItems: 1
> >  maxItems: 2
> >
> > +  idt,xtal1-load-femtofarads:
> > +$ref: /schemas/types.yaml#/definitions/uint32
>
> Already has a type, so you can drop the $ref.
>
> > +minimum: 9000
> > +maximum: 25000

Luca,

Do you want the range to the 9000 - 25000 per the datasheet, or should
I use the max value based on the programmer guide?  Currently, my
intent was to cap the value to 1b, so anyone who writes 23000,
24000, or 25000 will all be the same value based on the feedback I got
from Renesas.

adam
> > +description: Optional loading capacitor for XTAL1
> > +
> > +  idt,xtal2-load-femtofarads:
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 9000
> > +maximum: 25000
> > +description: Optional loading capacitor for XTAL2
> > +
> >  patternProperties:
> >"^OUT[1-4]$":
> >  type: object
> > --
> > 2.25.1
> >


[PATCH] module: invoke kobject uevent before sending LIVE notification

2021-01-12 Thread Adam Zabrocki
The recent change "module: delay kobject uevent until after module init
call", while helping avoid a race between udev/systemd and the module
loader, made it unnecessarily more difficult to monitor kernel module
integrity by out-of-tree projects such as Linux Kernel Runtime Guard.

Specifically, that change delayed the kobject uevent unnecessarily too far,
to until after sending a MODULE_STATE_LIVE notification.  As the uevent
modifies internal state of the KOBJ itself, this violated the assumption
(non-guaranteed yet handy while we can maintain it) that the KOBJ remains
consistent and can be integrity-checked as soon as the module is LIVE.

To make all of these projects happy at once, move the kobject KOBJ_ADD
uevent to just before sending the MODULE_STATE_LIVE notification.

Fixes: 38dc717e9715 ("module: delay kobject uevent until after module init 
call")
Signed-off-by: Adam Zabrocki 
---
 kernel/module.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 4bf30e4b3eaa..7d56b1b07237 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3681,14 +3681,14 @@ static noinline int do_init_module(struct module *mod)
dump_stack();
}

+   /* Delay uevent until module has finished its init routine */
+   kobject_uevent(>mkobj.kobj, KOBJ_ADD);
+
/* Now it's a first class citizen! */
mod->state = MODULE_STATE_LIVE;
blocking_notifier_call_chain(_notify_list,
 MODULE_STATE_LIVE, mod);

-   /* Delay uevent until module has finished its init routine */
-   kobject_uevent(>mkobj.kobj, KOBJ_ADD);
-
/*
 * We need to finish all async code before the module init sequence
 * is done.  This has potential to deadlock.  For example, a newly


Re: [RFC 2/2] clk: vc5: Add support for optional load capacitance

2021-01-12 Thread Adam Ford
On Tue, Jan 12, 2021 at 10:45 AM Luca Ceresoli  wrote:
>
> Hi Adam,
>
> On 11/01/21 17:40, Adam Ford wrote:
> > On Sat, Jan 9, 2021 at 12:02 PM Luca Ceresoli  wrote:
> >>
> >> Hi Adam,
> >>
> >> On 09/01/21 04:00, Adam Ford wrote:
> >>> On Fri, Jan 8, 2021 at 4:49 PM Luca Ceresoli  
> >>> wrote:
> >>>>
> >>>> Hi Adam,
> >>>>
> >>>> On 06/01/21 18:39, Adam Ford wrote:
> >>>>> There are two registers which can set the load capacitance for
> >>>>> XTAL1 and XTAL2. These are optional registers when using an
> >>>>> external crystal.  Parse the device tree and set the
> >>>>> corresponding registers accordingly.
> >>>>
> >>>> No need to repeat the first 2 sentences, they are already in patch 1.
> >>>
> >>> The reason I did that was because if someone does a git log on the
> >>> individual file, they'd see the comment.  While it's redundant not, it
> >>> might not be as obvious in the future when looking back.   Not
> >>> everyone reviews the history of the binding, but the source files' git
> >>> logs usually have some value.   However, if you want me to drop it or
> >>> rephrase it, I can do that.
> >>
> >> Makes sense, I had never considered that before.
> >>
> >>>>> +static int vc5_map_cap_value(u32 femtofarads)
> >>>>> +{
> >>>>> + int mapped_value;
> >>>>> +
> >>>>> + /* The datasheet explicitly states 9000 - 25000 */
> >>>>> + if ((femtofarads < 9000) || (femtofarads > 25000))
> >>>>> + return -EINVAL;
> >>>>> +
> >>>>> + /* The lowest target we can hit is 9430, so exit if it's less */
> >>>>> + if (femtofarads < 9430)
> >>>>> + return 0;
> >>>>> +
> >>>>> + /*
> >>>>> +  * According to VersaClock 6E Programming Guide, there are 6
> >>>>> +  * bits which translate to 64 entries in XTAL registers 12 and
> >>>>> +  * 13. Because bits 0 and 1 increase the capacitance the
> >>>>> +  * same, some of the values can be repeated.  Plugging this
> >>>>> +  * into a spreadsheet and generating a trendline, the output
> >>>>> +  * equation becomes x = (y-9098.29) / 216.44, where 'y' is
> >>>>> +  * the desired capacitance in femtofarads, and x is the value
> >>>>> +  * of XTAL[5:0].
> >>>>> +  * To help with rounding, do fixed point math
> >>>>> +  */
> >>>>> + femtofarads *= 100;
> >>>>> + mapped_value = (femtofarads - 909829) / 21644;
> >>>>
> >>>> Thanks for the extensive comment, but I am confused. Not by your code
> >>>> which is very clean and readable, but by the chip documentation
> >>>> (disclaimer: I haven't read it in full depth).
> >>>
> >>> I was confused too since the datasheet and programmers manual differ a 
> >>> bit.
> >>>>
> >>>> The 5P49V6965 datasheet at page 17 clearly states capacitance can be
> >>>> increased in 0.5 pF steps. The "VersaClock 6E Family Register
> >>>> Descriptions and Programming Guide" at page 18 shows a table that allows
> >>>> 0.43 pF. Can you clarify how the thing works?
> >>>
> >>> I used the Versaclock 6E doc which is based on the following:
> >>>
> >>> BIT 5 - Add 6.92pF
> >>> BIT 4 - Add 3.46pF
> >>> BIT 3 - Add 1.73pF
> >>> BIT 2 - Add 0.86pF
> >>> Bit 1 - Add 0.43pF
> >>> Bit 0 - Add 0.43pF
> >>>
> >>> Because the Datasheet starts at 9pF, the math I used, assumes these
> >>> numbers are added to 9pF.
> >>> Because the datasheet shows the increments are in .5pF increments, the
> >>> 430nF seems close.  The datasheet shows 9pF - 25pF and based on the
> >>> programmer table, we could get close to 25pF by enabling all bits and
> >>> adding 9pF, however the math doesn't quite hit 25pF.
> >>>
> >>> For what it's worth I needed around 11.5pF, and with this patch, the
> >>> hardware engineer said our ppm went from around 70 ppm to around 4ppm.
> >>
> >> Did he me

  1   2   3   4   5   6   7   8   9   10   >