i.MX95's several MIXes has BLK CTL module which could be used for
clk settings, QoS settings, Misc settings for a MIX. This patchset
is to add the clk feature support, including dt-bindings
Signed-off-by: Peng Fan <[email protected]>
---
Changes in v4:
- Separate binding doc for each modules, I still keep the syscon as node
name, because the module is not just for clock
- Pass dt-schema check
- Update node compatibles
- Link to v3: https://lore.kernel.org/r/[email protected]
Changes in v3:
- Correct example node compatible string
- Pass "make ARCH=arm64 DT_CHECKER_FLAGS=-m -j32 dt_binding_check"
- Link to v2: https://lore.kernel.org/r/[email protected]
Changes in v2:
- Correct example node compatible string
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Peng Fan (6):
dt-bindindgs: clock: nxp: support i.MX95 VPU CSR module
dt-bindindgs: clock: nxp: support i.MX95 Camera CSR module
dt-bindindgs: clock: nxp: support i.MX95 Display Master CSR module
dt-bindindgs: clock: nxp: support i.MX95 LVDS CSR module
dt-bindindgs: clock: nxp: support i.MX95 Display CSR module
clk: imx: add i.MX95 BLK CTL clk driver
.../bindings/clock/nxp,imx95-camera-csr.yaml | 50 +++
.../bindings/clock/nxp,imx95-display-csr.yaml | 50 +++
.../clock/nxp,imx95-display-master-csr.yaml | 62 +++
.../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 +++
.../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 +++
drivers/clk/imx/Kconfig | 7 +
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx95-blk-ctl.c | 438 +++++++++++++++++++++
include/dt-bindings/clock/nxp,imx95-clock.h | 32 ++
9 files changed, 740 insertions(+)
---
base-commit: c9c32620af65fee2b1ac8390fe1349b33f9d0888
change-id: 20240228-imx95-blk-ctl-9ef8c1fc4c22
Best regards,
--
Peng Fan <[email protected]>
From: Peng Fan <[email protected]>
i.MX95 DISPLAY_MASTER_CSR includes registers to control DSI clock settings,
clock gating, and pixel link select. Add dt-binding for it.
Signed-off-by: Peng Fan <[email protected]>
---
.../clock/nxp,imx95-display-master-csr.yaml | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
new file mode 100644
index 000000000000..ed0ec3a24d09
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-display-master-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Display Master Block Control
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-display-master-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+ mux-controller:
+ type: object
+ $ref: /schemas/mux/reg-mux.yaml
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - mux-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-display-master-csr", "syscon";
+ reg = <0x4c410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 62>;
+ power-domains = <&scmi_devpd 3>;
+
+ mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4 0x00000001>; /* Pixel_link_sel */
+ idle-states = <0>;
+ };
+ };
+...
--
2.37.1
From: Peng Fan <[email protected]>
The DISPLAY_CSR provides control and status of the following:
Clock selection for the Display Engines
Pixel Interleaver mode selection
Pixel Link enables
QoS settings for the display controller
ArCache and AwCache signals
Display Engine plane association
This patch is to add the clock features for this module
Signed-off-by: Peng Fan <[email protected]>
---
.../bindings/clock/nxp,imx95-display-csr.yaml | 50 ++++++++++++++++++++++
include/dt-bindings/clock/nxp,imx95-clock.h | 4 ++
2 files changed, 54 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
new file mode 100644
index 000000000000..9a5e21346b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-display-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Display Block Control
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-display-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-display-csr", "syscon";
+ reg = <0x4b010000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 75>;
+ power-domains = <&scmi_devpd 13>;
+ };
+...
diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
index e642a54c81a0..83fa3ffe78a8 100644
--- a/include/dt-bindings/clock/nxp,imx95-clock.h
+++ b/include/dt-bindings/clock/nxp,imx95-clock.h
@@ -25,4 +25,8 @@
#define IMX95_CLK_DISPMIX_PIX_DI1_GATE 4
#define IMX95_CLK_DISPMIX_LVDS_CSR_END 5
+#define IMX95_CLK_DISPMIX_ENG0_SEL 0
+#define IMX95_CLK_DISPMIX_ENG1_SEL 1
+#define IMX95_CLK_DISPMIX_END 2
+
#endif /* __DT_BINDINGS_CLOCK_IMX95_H */
--
2.37.1
From: Peng Fan <[email protected]>
i.MX95 has BLK CTL modules in various MIXes, the BLK CTL modules
support clock features such as mux/gate/div. This patch
is to add the clock feature of BLK CTL modules
Signed-off-by: Peng Fan <[email protected]>
---
drivers/clk/imx/Kconfig | 7 +
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx95-blk-ctl.c | 438 ++++++++++++++++++++++++++++++++++++
3 files changed, 446 insertions(+)
diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
index db3bca5f4ec9..6da0fba68225 100644
--- a/drivers/clk/imx/Kconfig
+++ b/drivers/clk/imx/Kconfig
@@ -114,6 +114,13 @@ config CLK_IMX93
help
Build the driver for i.MX93 CCM Clock Driver
+config CLK_IMX95_BLK_CTL
+ tristate "IMX95 Clock Driver for BLK CTL"
+ depends on ARCH_MXC || COMPILE_TEST
+ select MXC_CLK
+ help
+ Build the clock driver for i.MX95 BLK CTL
+
config CLK_IMXRT1050
tristate "IMXRT1050 CCM Clock Driver"
depends on SOC_IMXRT || COMPILE_TEST
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index d4b8e10b1970..03f2b2a1ab63 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_CLK_IMX8MP) += clk-imx8mp.o clk-imx8mp-audiomix.o
obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
obj-$(CONFIG_CLK_IMX93) += clk-imx93.o
+obj-$(CONFIG_CLK_IMX95_BLK_CTL) += clk-imx95-blk-ctl.o
obj-$(CONFIG_MXC_CLK_SCU) += clk-imx-scu.o clk-imx-lpcg-scu.o clk-imx-acm.o
clk-imx-scu-$(CONFIG_CLK_IMX8QXP) += clk-scu.o clk-imx8qxp.o \
diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c b/drivers/clk/imx/clk-imx95-blk-ctl.c
new file mode 100644
index 000000000000..afda463e28b1
--- /dev/null
+++ b/drivers/clk/imx/clk-imx95-blk-ctl.c
@@ -0,0 +1,438 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2024 NXP
+ */
+
+#include <dt-bindings/clock/nxp,imx95-clock.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/pm_runtime.h>
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+enum {
+ CLK_GATE,
+ CLK_DIVIDER,
+ CLK_MUX,
+};
+
+struct imx95_blk_ctl {
+ struct device *dev;
+ spinlock_t lock;
+ struct clk *clk_apb;
+
+ void __iomem *base;
+ /* clock gate register */
+ u32 clk_reg_restore;
+};
+
+struct imx95_blk_ctl_clk_dev_data {
+ const char *name;
+ const char * const *parent_names;
+ u32 num_parents;
+ u32 reg;
+ u32 bit_idx;
+ u32 bit_width;
+ u32 clk_type;
+ u32 flags;
+ u32 flags2;
+ u32 type;
+};
+
+struct imx95_blk_ctl_dev_data {
+ const struct imx95_blk_ctl_clk_dev_data *clk_dev_data;
+ u32 num_clks;
+ bool rpm_enabled;
+ u32 clk_reg_offset;
+};
+
+static const struct imx95_blk_ctl_clk_dev_data vpublk_clk_dev_data[] = {
+ [IMX95_CLK_VPUBLK_WAVE] = {
+ .name = "vpublk_wave_vpu",
+ .parent_names = (const char *[]){ "vpu", },
+ .num_parents = 1,
+ .reg = 8,
+ .bit_idx = 0,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_VPUBLK_JPEG_ENC] = {
+ .name = "vpublk_jpeg_enc",
+ .parent_names = (const char *[]){ "vpujpeg", },
+ .num_parents = 1,
+ .reg = 8,
+ .bit_idx = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_VPUBLK_JPEG_DEC] = {
+ .name = "vpublk_jpeg_dec",
+ .parent_names = (const char *[]){ "vpujpeg", },
+ .num_parents = 1,
+ .reg = 8,
+ .bit_idx = 2,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ }
+};
+
+static const struct imx95_blk_ctl_dev_data vpublk_dev_data = {
+ .num_clks = IMX95_CLK_VPUBLK_END,
+ .clk_dev_data = vpublk_clk_dev_data,
+ .rpm_enabled = true,
+ .clk_reg_offset = 8,
+};
+
+static const struct imx95_blk_ctl_clk_dev_data camblk_clk_dev_data[] = {
+ [IMX95_CLK_CAMBLK_CSI2_FOR0] = {
+ .name = "camblk_csi2_for0",
+ .parent_names = (const char *[]){ "camisi", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 0,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_CAMBLK_CSI2_FOR1] = {
+ .name = "camblk_csi2_for1",
+ .parent_names = (const char *[]){ "camisi", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_CAMBLK_ISP_AXI] = {
+ .name = "camblk_isp_axi",
+ .parent_names = (const char *[]){ "camaxi", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 4,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_CAMBLK_ISP_PIXEL] = {
+ .name = "camblk_isp_pixel",
+ .parent_names = (const char *[]){ "camisi", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 5,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_CAMBLK_ISP] = {
+ .name = "camblk_isp",
+ .parent_names = (const char *[]){ "camisi", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 6,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ }
+};
+
+static const struct imx95_blk_ctl_dev_data camblk_dev_data = {
+ .num_clks = IMX95_CLK_CAMBLK_END,
+ .clk_dev_data = camblk_clk_dev_data,
+ .clk_reg_offset = 0,
+};
+
+static const struct imx95_blk_ctl_clk_dev_data lvds_clk_dev_data[] = {
+ [IMX95_CLK_DISPMIX_LVDS_PHY_DIV] = {
+ .name = "ldb_phy_div",
+ .parent_names = (const char *[]){ "ldbpll", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 0,
+ .bit_width = 1,
+ .type = CLK_DIVIDER,
+ .flags2 = CLK_DIVIDER_POWER_OF_TWO,
+ },
+ [IMX95_CLK_DISPMIX_LVDS_CH0_GATE] = {
+ .name = "lvds_ch0_gate",
+ .parent_names = (const char *[]){ "ldb_phy_div", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 1,
+ .bit_width = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_DISPMIX_LVDS_CH1_GATE] = {
+ .name = "lvds_ch1_gate",
+ .parent_names = (const char *[]){ "ldb_phy_div", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 2,
+ .bit_width = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_DISPMIX_PIX_DI0_GATE] = {
+ .name = "lvds_di0_gate",
+ .parent_names = (const char *[]){ "ldb_pll_div7", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 3,
+ .bit_width = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+ [IMX95_CLK_DISPMIX_PIX_DI1_GATE] = {
+ .name = "lvds_di1_gate",
+ .parent_names = (const char *[]){ "ldb_pll_div7", },
+ .num_parents = 1,
+ .reg = 0,
+ .bit_idx = 4,
+ .bit_width = 1,
+ .type = CLK_GATE,
+ .flags = CLK_SET_RATE_PARENT,
+ .flags2 = CLK_GATE_SET_TO_DISABLE,
+ },
+};
+
+static const struct imx95_blk_ctl_dev_data lvds_csr_dev_data = {
+ .num_clks = IMX95_CLK_DISPMIX_LVDS_CSR_END,
+ .clk_dev_data = lvds_clk_dev_data,
+ .clk_reg_offset = 0,
+};
+
+static const struct imx95_blk_ctl_clk_dev_data dispmix_csr_clk_dev_data[] = {
+ [IMX95_CLK_DISPMIX_ENG0_SEL] = {
+ .name = "disp_engine0_sel",
+ .parent_names = (const char *[]){"videopll1", "dsi_pll", "ldb_pll_div7", },
+ .num_parents = 4,
+ .reg = 0,
+ .bit_idx = 0,
+ .bit_width = 2,
+ .type = CLK_MUX,
+ .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
+ },
+ [IMX95_CLK_DISPMIX_ENG1_SEL] = {
+ .name = "disp_engine1_sel",
+ .parent_names = (const char *[]){"videopll1", "dsi_pll", "ldb_pll_div7", },
+ .num_parents = 4,
+ .reg = 0,
+ .bit_idx = 2,
+ .bit_width = 2,
+ .type = CLK_MUX,
+ .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
+ }
+};
+
+static const struct imx95_blk_ctl_dev_data dispmix_csr_dev_data = {
+ .num_clks = IMX95_CLK_DISPMIX_END,
+ .clk_dev_data = dispmix_csr_clk_dev_data,
+ .clk_reg_offset = 0,
+};
+
+static int imx95_bc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct imx95_blk_ctl_dev_data *bc_data;
+ struct imx95_blk_ctl *bc;
+ struct clk_hw_onecell_data *clk_hw_data;
+ struct clk_hw **hws;
+ void __iomem *base;
+ int i, ret;
+
+ bc = devm_kzalloc(dev, sizeof(*bc), GFP_KERNEL);
+ if (!bc)
+ return -ENOMEM;
+ bc->dev = dev;
+ dev_set_drvdata(&pdev->dev, bc);
+
+ spin_lock_init(&bc->lock);
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ bc->base = base;
+ bc->clk_apb = devm_clk_get(dev, NULL);
+ if (IS_ERR(bc->clk_apb))
+ return dev_err_probe(dev, PTR_ERR(bc->clk_apb), "failed to get APB clock\n");
+
+ ret = clk_prepare_enable(bc->clk_apb);
+ if (ret) {
+ dev_err(dev, "failed to enable apb clock: %d\n", ret);
+ return ret;
+ }
+
+ bc_data = of_device_get_match_data(dev);
+ if (!bc_data)
+ return devm_of_platform_populate(dev);
+
+ clk_hw_data = devm_kzalloc(dev, struct_size(clk_hw_data, hws, bc_data->num_clks),
+ GFP_KERNEL);
+ if (!clk_hw_data)
+ return -ENOMEM;
+
+ if (bc_data->rpm_enabled)
+ pm_runtime_enable(&pdev->dev);
+
+ clk_hw_data->num = bc_data->num_clks;
+ hws = clk_hw_data->hws;
+
+ for (i = 0; i < bc_data->num_clks; i++) {
+ const struct imx95_blk_ctl_clk_dev_data *data = &bc_data->clk_dev_data[i];
+ void __iomem *reg = base + data->reg;
+
+ if (data->type == CLK_MUX) {
+ hws[i] = clk_hw_register_mux(dev, data->name, data->parent_names,
+ data->num_parents, data->flags, reg,
+ data->bit_idx, data->bit_width,
+ data->flags2, &bc->lock);
+ } else if (data->type == CLK_DIVIDER) {
+ hws[i] = clk_hw_register_divider(dev, data->name, data->parent_names[0],
+ data->flags, reg, data->bit_idx,
+ data->bit_width, data->flags2, &bc->lock);
+ } else {
+ hws[i] = clk_hw_register_gate(dev, data->name, data->parent_names[0],
+ data->flags, reg, data->bit_idx,
+ data->flags2, &bc->lock);
+ }
+ if (IS_ERR(hws[i])) {
+ ret = PTR_ERR(hws[i]);
+ dev_err(dev, "failed to register: %s:%d\n", data->name, ret);
+ goto cleanup;
+ }
+ }
+
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get, clk_hw_data);
+ if (ret)
+ goto cleanup;
+
+ ret = devm_of_platform_populate(dev);
+ if (ret) {
+ of_clk_del_provider(dev->of_node);
+ goto cleanup;
+ }
+
+ if (pm_runtime_enabled(bc->dev))
+ clk_disable_unprepare(bc->clk_apb);
+
+ return 0;
+
+cleanup:
+ for (i = 0; i < bc_data->num_clks; i++) {
+ if (IS_ERR_OR_NULL(hws[i]))
+ continue;
+ clk_hw_unregister(hws[i]);
+ }
+
+ if (bc_data->rpm_enabled)
+ pm_runtime_disable(&pdev->dev);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM
+static int imx95_bc_runtime_suspend(struct device *dev)
+{
+ struct imx95_blk_ctl *bc = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(bc->clk_apb);
+ return 0;
+}
+
+static int imx95_bc_runtime_resume(struct device *dev)
+{
+ struct imx95_blk_ctl *bc = dev_get_drvdata(dev);
+
+ return clk_prepare_enable(bc->clk_apb);
+}
+#endif
+
+#ifdef CONFIG_PM_SLEEP
+static int imx95_bc_suspend(struct device *dev)
+{
+ struct imx95_blk_ctl *bc = dev_get_drvdata(dev);
+ const struct imx95_blk_ctl_dev_data *bc_data;
+ int ret;
+
+ bc_data = of_device_get_match_data(dev);
+ if (!bc_data)
+ return 0;
+
+ if (bc_data->rpm_enabled) {
+ ret = pm_runtime_get_sync(bc->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(bc->dev);
+ return ret;
+ }
+ }
+
+ bc->clk_reg_restore = readl(bc->base + bc_data->clk_reg_offset);
+
+ return 0;
+}
+
+static int imx95_bc_resume(struct device *dev)
+{
+ struct imx95_blk_ctl *bc = dev_get_drvdata(dev);
+ const struct imx95_blk_ctl_dev_data *bc_data;
+
+ bc_data = of_device_get_match_data(dev);
+ if (!bc_data)
+ return 0;
+
+ writel(bc->clk_reg_restore, bc->base + bc_data->clk_reg_offset);
+
+ if (bc_data->rpm_enabled)
+ pm_runtime_put(bc->dev);
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops imx95_bc_pm_ops = {
+ SET_RUNTIME_PM_OPS(imx95_bc_runtime_suspend, imx95_bc_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(imx95_bc_suspend, imx95_bc_resume)
+};
+
+static const struct of_device_id imx95_bc_of_match[] = {
+ { .compatible = "nxp,imx95-camera-csr", .data = &camblk_dev_data },
+ { .compatible = "nxp,imx95-display-master-csr", },
+ { .compatible = "nxp,imx95-lvds-csr", .data = &lvds_csr_dev_data },
+ { .compatible = "nxp,imx95-display-csr", .data = &dispmix_csr_dev_data },
+ { .compatible = "nxp,imx95-vpu-csr", .data = &vpublk_dev_data },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, imx95_bc_of_match);
+
+static struct platform_driver imx95_bc_driver = {
+ .probe = imx95_bc_probe,
+ .driver = {
+ .name = "imx95-blk-ctl",
+ .of_match_table = of_match_ptr(imx95_bc_of_match),
+ .pm = &imx95_bc_pm_ops,
+ },
+};
+module_platform_driver(imx95_bc_driver);
+
+MODULE_DESCRIPTION("NXP i.MX95 blk ctl driver");
+MODULE_AUTHOR("Peng Fan <[email protected]>");
+MODULE_LICENSE("GPL");
--
2.37.1
From: Peng Fan <[email protected]>
The i.MX95 LVDS_CSR provides clock gate controls for the LVDS units, LVDS
PHY and Pixel Mapper blocks. Add dt-binding for it.
Signed-off-by: Peng Fan <[email protected]>
---
.../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 ++++++++++++++++++++++
include/dt-bindings/clock/nxp,imx95-clock.h | 7 +++
2 files changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml
new file mode 100644
index 000000000000..e04f0ca4f588
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-lvds-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Display LVDS Block Control
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-lvds-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-lvds-csr", "syscon";
+ reg = <0x4c410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 75>;
+ power-domains = <&scmi_devpd 13>;
+ };
+...
diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
index c671c4dbb4d5..e642a54c81a0 100644
--- a/include/dt-bindings/clock/nxp,imx95-clock.h
+++ b/include/dt-bindings/clock/nxp,imx95-clock.h
@@ -18,4 +18,11 @@
#define IMX95_CLK_CAMBLK_ISP 4
#define IMX95_CLK_CAMBLK_END 5
+#define IMX95_CLK_DISPMIX_LVDS_PHY_DIV 0
+#define IMX95_CLK_DISPMIX_LVDS_CH0_GATE 1
+#define IMX95_CLK_DISPMIX_LVDS_CH1_GATE 2
+#define IMX95_CLK_DISPMIX_PIX_DI0_GATE 3
+#define IMX95_CLK_DISPMIX_PIX_DI1_GATE 4
+#define IMX95_CLK_DISPMIX_LVDS_CSR_END 5
+
#endif /* __DT_BINDINGS_CLOCK_IMX95_H */
--
2.37.1
From: Peng Fan <[email protected]>
The i.MX95 VPU_CSR contains control and status registers for VPU
status, pending transaction status, and clock gating controls.
This patch is to add clock features for VPU CSR.
Signed-off-by: Peng Fan <[email protected]>
---
.../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 ++++++++++++++++++++++
include/dt-bindings/clock/nxp,imx95-clock.h | 14 ++++++
2 files changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
new file mode 100644
index 000000000000..4a1c6dcfe3f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-vpu-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 VPUMIX Block Control
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-vpu-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-vpu-csr", "syscon";
+ reg = <0x4c410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 114>;
+ power-domains = <&scmi_devpd 21>;
+ };
+...
diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
new file mode 100644
index 000000000000..9d8f0a6d12d0
--- /dev/null
+++ b/include/dt-bindings/clock/nxp,imx95-clock.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/*
+ * Copyright 2024 NXP
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_IMX95_H
+#define __DT_BINDINGS_CLOCK_IMX95_H
+
+#define IMX95_CLK_VPUBLK_WAVE 0
+#define IMX95_CLK_VPUBLK_JPEG_ENC 1
+#define IMX95_CLK_VPUBLK_JPEG_DEC 2
+#define IMX95_CLK_VPUBLK_END 3
+
+#endif /* __DT_BINDINGS_CLOCK_IMX95_H */
--
2.37.1
From: Peng Fan <[email protected]>
The i.MX95 Camera CSR is a set of registers that provides various
configuration and status of the Camera modules’ operations. Registers
are available to enable clock gating to the ISP and CSI-2 pixel
formatters, enable transport of various pixel data and non-pixel data
types, control their routing, and other functions. Status registers
provide pixel data type error information and pending transaction
from Camera NoC initiators.
This patch is to add clock features for Camera CSR.
Signed-off-by: Peng Fan <[email protected]>
---
.../bindings/clock/nxp,imx95-camera-csr.yaml | 50 ++++++++++++++++++++++
include/dt-bindings/clock/nxp,imx95-clock.h | 7 +++
2 files changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml
new file mode 100644
index 000000000000..e62494e3a8b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/nxp,imx95-camera-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX95 Camera MIX Block Control
+
+maintainers:
+ - Peng Fan <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - const: nxp,imx95-camera-csr
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+ description:
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See
+ include/dt-bindings/clock/nxp,imx95-clock.h
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ syscon@4c410000 {
+ compatible = "nxp,imx95-camera-csr", "syscon";
+ reg = <0x4ac10000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&scmi_clk 62>;
+ power-domains = <&scmi_devpd 3>;
+ };
+...
diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
index 9d8f0a6d12d0..c671c4dbb4d5 100644
--- a/include/dt-bindings/clock/nxp,imx95-clock.h
+++ b/include/dt-bindings/clock/nxp,imx95-clock.h
@@ -11,4 +11,11 @@
#define IMX95_CLK_VPUBLK_JPEG_DEC 2
#define IMX95_CLK_VPUBLK_END 3
+#define IMX95_CLK_CAMBLK_CSI2_FOR0 0
+#define IMX95_CLK_CAMBLK_CSI2_FOR1 1
+#define IMX95_CLK_CAMBLK_ISP_AXI 2
+#define IMX95_CLK_CAMBLK_ISP_PIXEL 3
+#define IMX95_CLK_CAMBLK_ISP 4
+#define IMX95_CLK_CAMBLK_END 5
+
#endif /* __DT_BINDINGS_CLOCK_IMX95_H */
--
2.37.1
On Thu, Mar 14, 2024 at 09:25:10PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The i.MX95 VPU_CSR contains control and status registers for VPU
> status, pending transaction status, and clock gating controls.
>
> This patch is to add clock features for VPU CSR.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 ++++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 14 ++++++
> 2 files changed, 64 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> new file mode 100644
> index 000000000000..4a1c6dcfe3f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-vpu-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 VPUMIX Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-vpu-csr
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> + description:
> + The clock consumer should specify the desired clock by having the clock
> + ID in its "clocks" phandle cell. See
> + include/dt-bindings/clock/nxp,imx95-clock.h
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + syscon@4c410000 {
> + compatible = "nxp,imx95-vpu-csr", "syscon";
> + reg = <0x4c410000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 114>;
> + power-domains = <&scmi_devpd 21>;
> + };
> +...
> diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
> new file mode 100644
> index 000000000000..9d8f0a6d12d0
> --- /dev/null
> +++ b/include/dt-bindings/clock/nxp,imx95-clock.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> +/*
> + * Copyright 2024 NXP
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_IMX95_H
> +#define __DT_BINDINGS_CLOCK_IMX95_H
> +
> +#define IMX95_CLK_VPUBLK_WAVE 0
> +#define IMX95_CLK_VPUBLK_JPEG_ENC 1
> +#define IMX95_CLK_VPUBLK_JPEG_DEC 2
> +#define IMX95_CLK_VPUBLK_END 3
If this number can change, then it is not ABI and doesn't go in this
header. With that dropped,
Reviewed-by: Rob Herring <[email protected]>
On Thu, Mar 14, 2024 at 09:25:11PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The i.MX95 Camera CSR is a set of registers that provides various
> configuration and status of the Camera modules’ operations. Registers
> are available to enable clock gating to the ISP and CSI-2 pixel
> formatters, enable transport of various pixel data and non-pixel data
> types, control their routing, and other functions. Status registers
> provide pixel data type error information and pending transaction
> from Camera NoC initiators.
>
> This patch is to add clock features for Camera CSR.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../bindings/clock/nxp,imx95-camera-csr.yaml | 50 ++++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 7 +++
> 2 files changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml
> new file mode 100644
> index 000000000000..e62494e3a8b1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-camera-csr.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-camera-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 Camera MIX Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-camera-csr
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> + description:
> + The clock consumer should specify the desired clock by having the clock
> + ID in its "clocks" phandle cell. See
> + include/dt-bindings/clock/nxp,imx95-clock.h
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + syscon@4c410000 {
> + compatible = "nxp,imx95-camera-csr", "syscon";
> + reg = <0x4ac10000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 62>;
> + power-domains = <&scmi_devpd 3>;
> + };
> +...
> diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
> index 9d8f0a6d12d0..c671c4dbb4d5 100644
> --- a/include/dt-bindings/clock/nxp,imx95-clock.h
> +++ b/include/dt-bindings/clock/nxp,imx95-clock.h
> @@ -11,4 +11,11 @@
> #define IMX95_CLK_VPUBLK_JPEG_DEC 2
> #define IMX95_CLK_VPUBLK_END 3
>
> +#define IMX95_CLK_CAMBLK_CSI2_FOR0 0
> +#define IMX95_CLK_CAMBLK_CSI2_FOR1 1
> +#define IMX95_CLK_CAMBLK_ISP_AXI 2
> +#define IMX95_CLK_CAMBLK_ISP_PIXEL 3
> +#define IMX95_CLK_CAMBLK_ISP 4
> +#define IMX95_CLK_CAMBLK_END 5
Same issue here. With that dropped,
Reviewed-by: Rob Herring <[email protected]>
On Thu, Mar 14, 2024 at 09:25:12PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> i.MX95 DISPLAY_MASTER_CSR includes registers to control DSI clock settings,
> clock gating, and pixel link select. Add dt-binding for it.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../clock/nxp,imx95-display-master-csr.yaml | 62 ++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
> new file mode 100644
> index 000000000000..ed0ec3a24d09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-display-master-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 Display Master Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-display-master-csr
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> + description:
> + The clock consumer should specify the desired clock by having the clock
> + ID in its "clocks" phandle cell. See
> + include/dt-bindings/clock/nxp,imx95-clock.h
Forget this header changes here?
On Thu, Mar 14, 2024 at 09:25:13PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The i.MX95 LVDS_CSR provides clock gate controls for the LVDS units, LVDS
> PHY and Pixel Mapper blocks. Add dt-binding for it.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 ++++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 7 +++
> 2 files changed, 57 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml
> new file mode 100644
> index 000000000000..e04f0ca4f588
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-lvds-csr.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-lvds-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 Display LVDS Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-lvds-csr
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> + description:
> + The clock consumer should specify the desired clock by having the clock
> + ID in its "clocks" phandle cell. See
> + include/dt-bindings/clock/nxp,imx95-clock.h
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
How are clocks and power-domains optional?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + syscon@4c410000 {
> + compatible = "nxp,imx95-lvds-csr", "syscon";
> + reg = <0x4c410000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 75>;
> + power-domains = <&scmi_devpd 13>;
> + };
> +...
> diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
> index c671c4dbb4d5..e642a54c81a0 100644
> --- a/include/dt-bindings/clock/nxp,imx95-clock.h
> +++ b/include/dt-bindings/clock/nxp,imx95-clock.h
> @@ -18,4 +18,11 @@
> #define IMX95_CLK_CAMBLK_ISP 4
> #define IMX95_CLK_CAMBLK_END 5
>
> +#define IMX95_CLK_DISPMIX_LVDS_PHY_DIV 0
> +#define IMX95_CLK_DISPMIX_LVDS_CH0_GATE 1
> +#define IMX95_CLK_DISPMIX_LVDS_CH1_GATE 2
> +#define IMX95_CLK_DISPMIX_PIX_DI0_GATE 3
> +#define IMX95_CLK_DISPMIX_PIX_DI1_GATE 4
> +#define IMX95_CLK_DISPMIX_LVDS_CSR_END 5
Same issue here.
On 14/03/2024 14:25, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The i.MX95 VPU_CSR contains control and status registers for VPU
> status, pending transaction status, and clock gating controls.
>
> This patch is to add clock features for VPU CSR.
Fix the subject prefix. You mess with people's filters.
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 ++++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 14 ++++++
> 2 files changed, 64 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> new file mode 100644
> index 000000000000..4a1c6dcfe3f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-vpu-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 VPUMIX Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-vpu-csr
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + '#clock-cells':
> + const: 1
> + description:
> + The clock consumer should specify the desired clock by having the clock
> + ID in its "clocks" phandle cell. See
> + include/dt-bindings/clock/nxp,imx95-clock.h
> +
> +required:
> + - compatible
> + - reg
> + - '#clock-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + syscon@4c410000 {
> + compatible = "nxp,imx95-vpu-csr", "syscon";
> + reg = <0x4c410000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 114>;
> + power-domains = <&scmi_devpd 21>;
> + };
> +...
> diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h b/include/dt-bindings/clock/nxp,imx95-clock.h
> new file mode 100644
> index 000000000000..9d8f0a6d12d0
> --- /dev/null
> +++ b/include/dt-bindings/clock/nxp,imx95-clock.h
If the header is only for clock IDs for this binding, then keep the same
filename as binding filename.
Best regards,
Krzysztof
On 14/03/2024 14:25, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> The DISPLAY_CSR provides control and status of the following:
> Clock selection for the Display Engines
> Pixel Interleaver mode selection
> Pixel Link enables
> QoS settings for the display controller
> ArCache and AwCache signals
> Display Engine plane association
>
> This patch is to add the clock features for this module
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> .../bindings/clock/nxp,imx95-display-csr.yaml | 50 ++++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 4 ++
> 2 files changed, 54 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
> new file mode 100644
> index 000000000000..9a5e21346b0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/nxp,imx95-display-csr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP i.MX95 Display Block Control
> +
> +maintainers:
> + - Peng Fan <[email protected]>
> +
> +properties:
> + compatible:
> + items:
> + - const: nxp,imx95-display-csr
> + - const: syscon
Why do you create five different bindings with almost the same contents?
Do you plan to grow on them, like add more compatibles here? Otherwise
all this could be in one binding.
Best regards,
Krzysztof
Hi Peng,
thank for the patchset.
On 24-03-14, Peng Fan (OSS) wrote:
> i.MX95's several MIXes has BLK CTL module which could be used for
> clk settings, QoS settings, Misc settings for a MIX. This patchset
> is to add the clk feature support, including dt-bindings
I have to ask since there is almost no public documentation available
yet. The i.MX95 does have an system-controller for managing pinmux
settings and power-domains, right? If this is the case, why not making
use of it via the standard scmi_pm_domain.c driver?
Regards,
Marco
>
> Signed-off-by: Peng Fan <[email protected]>
> ---
> Changes in v4:
> - Separate binding doc for each modules, I still keep the syscon as node
> name, because the module is not just for clock
> - Pass dt-schema check
> - Update node compatibles
> - Link to v3: https://lore.kernel.org/r/[email protected]
>
> Changes in v3:
> - Correct example node compatible string
> - Pass "make ARCH=arm64 DT_CHECKER_FLAGS=-m -j32 dt_binding_check"
> - Link to v2: https://lore.kernel.org/r/[email protected]
>
> Changes in v2:
> - Correct example node compatible string
> - Link to v1: https://lore.kernel.org/r/[email protected]
>
> ---
> Peng Fan (6):
> dt-bindindgs: clock: nxp: support i.MX95 VPU CSR module
> dt-bindindgs: clock: nxp: support i.MX95 Camera CSR module
> dt-bindindgs: clock: nxp: support i.MX95 Display Master CSR module
> dt-bindindgs: clock: nxp: support i.MX95 LVDS CSR module
> dt-bindindgs: clock: nxp: support i.MX95 Display CSR module
> clk: imx: add i.MX95 BLK CTL clk driver
>
> .../bindings/clock/nxp,imx95-camera-csr.yaml | 50 +++
> .../bindings/clock/nxp,imx95-display-csr.yaml | 50 +++
> .../clock/nxp,imx95-display-master-csr.yaml | 62 +++
> .../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 +++
> .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 +++
> drivers/clk/imx/Kconfig | 7 +
> drivers/clk/imx/Makefile | 1 +
> drivers/clk/imx/clk-imx95-blk-ctl.c | 438 +++++++++++++++++++++
> include/dt-bindings/clock/nxp,imx95-clock.h | 32 ++
> 9 files changed, 740 insertions(+)
> ---
> base-commit: c9c32620af65fee2b1ac8390fe1349b33f9d0888
> change-id: 20240228-imx95-blk-ctl-9ef8c1fc4c22
>
> Best regards,
> --
> Peng Fan <[email protected]>
>
>
>
Hi Marco,
> Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> features
>
> Hi Peng,
>
> thank for the patchset.
>
> On 24-03-14, Peng Fan (OSS) wrote:
> > i.MX95's several MIXes has BLK CTL module which could be used for clk
> > settings, QoS settings, Misc settings for a MIX. This patchset is to
> > add the clk feature support, including dt-bindings
>
> I have to ask since there is almost no public documentation available yet The
> i.MX95 does have an system-controller for managing pinmux settings and
> power-domains, right?
Yes.
If this is the case, why not making use of it via the
> standard scmi_pm_domain.c driver?
The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff is
a mix of clk, qos, module specific things. It is not good for SCMI firmare
to handle it.
Regards,
Peng.
>
> Regards,
> Marco
>
>
>
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > Changes in v4:
> > - Separate binding doc for each modules, I still keep the syscon as
> > node name, because the module is not just for clock
> > - Pass dt-schema check
> > - Update node compatibles
> > - Link to v3:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v3-0-
> 40ceba01a211%40nxp.com&d
> >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> b3952%7C
> >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969085566
> 1%7CUnknow
> >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLC
> >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=M%2B3lDY9BKvW0nHv4mtvi82RA
> 9IvYyz72TCbL
> > UpiYcG0%3D&reserved=0
> >
> > Changes in v3:
> > - Correct example node compatible string
> > - Pass "make ARCH=arm64 DT_CHECKER_FLAGS=-m -j32 dt_binding_check"
> > - Link to v2:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v2-0-
> ffb7eefb6dcd%40nxp.com&d
> >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> b3952%7C
> >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969086560
> 2%7CUnknow
> >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLC
> >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4leg49tKhwUMzvD5wlnvgVc7is%2
> FGMNvpYr6A
> > %2FAf3OU4%3D&reserved=0
> >
> > Changes in v2:
> > - Correct example node compatible string
> > - Link to v1:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v1-0-
> 9b5ae3c14d83%40nxp.com&d
> >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> b3952%7C
> >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969087217
> 2%7CUnknow
> >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLC
> >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UuD5MVPFgBqwftuXCIXB7SeGyu0
> NWPbwY%2Bvy
> > ChFLyVA%3D&reserved=0
> >
> > ---
> > Peng Fan (6):
> > dt-bindindgs: clock: nxp: support i.MX95 VPU CSR module
> > dt-bindindgs: clock: nxp: support i.MX95 Camera CSR module
> > dt-bindindgs: clock: nxp: support i.MX95 Display Master CSR module
> > dt-bindindgs: clock: nxp: support i.MX95 LVDS CSR module
> > dt-bindindgs: clock: nxp: support i.MX95 Display CSR module
> > clk: imx: add i.MX95 BLK CTL clk driver
> >
> > .../bindings/clock/nxp,imx95-camera-csr.yaml | 50 +++
> > .../bindings/clock/nxp,imx95-display-csr.yaml | 50 +++
> > .../clock/nxp,imx95-display-master-csr.yaml | 62 +++
> > .../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 +++
> > .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 +++
> > drivers/clk/imx/Kconfig | 7 +
> > drivers/clk/imx/Makefile | 1 +
> > drivers/clk/imx/clk-imx95-blk-ctl.c | 438 +++++++++++++++++++++
> > include/dt-bindings/clock/nxp,imx95-clock.h | 32 ++
> > 9 files changed, 740 insertions(+)
> > ---
> > base-commit: c9c32620af65fee2b1ac8390fe1349b33f9d0888
> > change-id: 20240228-imx95-blk-ctl-9ef8c1fc4c22
> >
> > Best regards,
> > --
> > Peng Fan <[email protected]>
> >
> >
> >
> Subject: Re: [PATCH v4 1/6] dt-bindindgs: clock: nxp: support i.MX95 VPU
> CSR module
>
> On 14/03/2024 14:25, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > The i.MX95 VPU_CSR contains control and status registers for VPU
> > status, pending transaction status, and clock gating controls.
> >
> > This patch is to add clock features for VPU CSR.
>
> Fix the subject prefix. You mess with people's filters.
Sorry, a typo error. Will fix it.
>
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50
> ++++++++++++++++++++++
> > include/dt-bindings/clock/nxp,imx95-clock.h | 14 ++++++
> > 2 files changed, 64 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> > b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> > new file mode 100644
> > index 000000000000..4a1c6dcfe3f8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-vpu-csr.yaml
> > @@ -0,0 +1,50 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fclock%2Fnxp%2Cimx95-vpu-
> csr.yaml%23&data=05%7C
> >
> +02%7Cpeng.fan%40nxp.com%7Cbd64d1b5d1784bdb6df508dc453133ca%7
> C686ea1d3
> >
> +bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638461324818682648%7CUnk
> nown%7CTWF
> >
> +pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6
> >
> +Mn0%3D%7C0%7C%7C%7C&sdata=PtStE2Y%2BnS4HpesF9wE66t8bh0Qmg
> 3s3y4aERwhSr
> > +Mo%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7Cbd64d1b5d1784bdb6df508dc453133ca%7C686ea1d3bc2b4c6fa
> 92cd99c5c
> >
> +301635%7C0%7C0%7C638461324818692719%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=zWKRFnTPTwLZvtOvOrFUo%2FNlqPKRqRIEYCrztlfhzAU%3D&reserv
> ed=0
> > +
> > +title: NXP i.MX95 VPUMIX Block Control
> > +
> > +maintainers:
> > + - Peng Fan <[email protected]>
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - const: nxp,imx95-vpu-csr
> > + - const: syscon
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + '#clock-cells':
> > + const: 1
> > + description:
> > + The clock consumer should specify the desired clock by having the
> clock
> > + ID in its "clocks" phandle cell. See
> > + include/dt-bindings/clock/nxp,imx95-clock.h
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - '#clock-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + syscon@4c410000 {
> > + compatible = "nxp,imx95-vpu-csr", "syscon";
> > + reg = <0x4c410000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&scmi_clk 114>;
> > + power-domains = <&scmi_devpd 21>;
> > + };
> > +...
> > diff --git a/include/dt-bindings/clock/nxp,imx95-clock.h
> > b/include/dt-bindings/clock/nxp,imx95-clock.h
> > new file mode 100644
> > index 000000000000..9d8f0a6d12d0
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/nxp,imx95-clock.h
>
> If the header is only for clock IDs for this binding, then keep the same
> filename as binding filename.
No, this file will also include other IDs in following patches.
Thanks,
Peng.
>
> Best regards,
> Krzysztof
On 24-03-18, Peng Fan wrote:
> Hi Marco,
>
> > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > features
> >
> > Hi Peng,
> >
> > thank for the patchset.
> >
> > On 24-03-14, Peng Fan (OSS) wrote:
> > > i.MX95's several MIXes has BLK CTL module which could be used for clk
> > > settings, QoS settings, Misc settings for a MIX. This patchset is to
> > > add the clk feature support, including dt-bindings
> >
> > I have to ask since there is almost no public documentation available yet. The
> > i.MX95 does have an system-controller for managing pinmux settings and
> > power-domains, right?
>
> Yes.
>
> If this is the case, why not making use of it via the
> > standard scmi_pm_domain.c driver?
>
> The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff is
> a mix of clk, qos, module specific things. It is not good for SCMI firmare
> to handle it.
Currently most of the blk-ctrl users do use the blk-ctrl as power-domain
consumer, except for the isi and the audio part. So as I said above the
scmi_pm_domain.c should be able to supply this. The audio blk-ctrl could
be abstracted via the clk-scmi.c driver. The ISI is another topic.
What you're are going to do here is to put pinctrl etc into SCMI
firmware and power-control into Linux, which sound to me like an 50/50
approach and IMHO is rather sub-optimal. To quote your online available
fact sheet:
8<----------------------------------------------------------
ENERGY FLEX ARCHITECTURE
The i,MX 95 family is designed to be configurable and
scalable, with multiple heterogenous processing domains.
This includes an application domain with up to 6 Arm
Cortex A55 cores, a high-performance real-time domain
with Arm Cortex M7, and low-power/safety domain with
Arm Cortex M33, each able to access interfaces including
CAN-FD, 10GbE networking, PCIe Gen 3 x1 interfaces,
and accelerators such as V2X, ISP, and VPU.
8<----------------------------------------------------------
8<----------------------------------------------------------
HIGH-PERFORMANCE COMPUTE
The i.MX 95 family capabilities include a multi-core
application domain with up to six Arm Cortex?-A55 cores,
as well as two independent real-time domains for
safety/low-power, and high-performance real-time use,
consisting of high-performance Arm Cortex-M7 and
Arm Cortex-M33 CPUs, combining low-power, real-time,
and high-performance processing. The i.MX 95 family is
designed to enable ISO 26262 ASIL-B and SIL-2 IEC 61508
compliant platforms, with the safety domain serving as
a critical capability for many automotive and industrial
applications.
..
8<----------------------------------------------------------
To me this sound like we can turn of the power/clock of an hardware
block which was assigned to a core running SIL-2 certified software from
an non-critical core running Linux if we follow that approach. Also the
SIL-2 software requires the non-critical software to turn on the power
of these hardware blocks. Is this correct?
Regards,
Marco
> Regards,
> Peng.
>
> >
> > Regards,
> > Marco
> >
> >
> >
> > >
> > > Signed-off-by: Peng Fan <[email protected]>
> > > ---
> > > Changes in v4:
> > > - Separate binding doc for each modules, I still keep the syscon as
> > > node name, because the module is not just for clock
> > > - Pass dt-schema check
> > > - Update node compatibles
> > > - Link to v3:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v3-0-
> > 40ceba01a211%40nxp.com&d
> > >
> > ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > b3952%7C
> > >
> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969085566
> > 1%7CUnknow
> > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLC
> > >
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=M%2B3lDY9BKvW0nHv4mtvi82RA
> > 9IvYyz72TCbL
> > > UpiYcG0%3D&reserved=0
> > >
> > > Changes in v3:
> > > - Correct example node compatible string
> > > - Pass "make ARCH=arm64 DT_CHECKER_FLAGS=-m -j32 dt_binding_check"
> > > - Link to v2:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v2-0-
> > ffb7eefb6dcd%40nxp.com&d
> > >
> > ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > b3952%7C
> > >
> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969086560
> > 2%7CUnknow
> > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLC
> > >
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4leg49tKhwUMzvD5wlnvgVc7is%2
> > FGMNvpYr6A
> > > %2FAf3OU4%3D&reserved=0
> > >
> > > Changes in v2:
> > > - Correct example node compatible string
> > > - Link to v1:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v1-0-
> > 9b5ae3c14d83%40nxp.com&d
> > >
> > ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > b3952%7C
> > >
> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969087217
> > 2%7CUnknow
> > >
> > n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > WwiLC
> > >
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UuD5MVPFgBqwftuXCIXB7SeGyu0
> > NWPbwY%2Bvy
> > > ChFLyVA%3D&reserved=0
> > >
> > > ---
> > > Peng Fan (6):
> > > dt-bindindgs: clock: nxp: support i.MX95 VPU CSR module
> > > dt-bindindgs: clock: nxp: support i.MX95 Camera CSR module
> > > dt-bindindgs: clock: nxp: support i.MX95 Display Master CSR module
> > > dt-bindindgs: clock: nxp: support i.MX95 LVDS CSR module
> > > dt-bindindgs: clock: nxp: support i.MX95 Display CSR module
> > > clk: imx: add i.MX95 BLK CTL clk driver
> > >
> > > .../bindings/clock/nxp,imx95-camera-csr.yaml | 50 +++
> > > .../bindings/clock/nxp,imx95-display-csr.yaml | 50 +++
> > > .../clock/nxp,imx95-display-master-csr.yaml | 62 +++
> > > .../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 +++
> > > .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 +++
> > > drivers/clk/imx/Kconfig | 7 +
> > > drivers/clk/imx/Makefile | 1 +
> > > drivers/clk/imx/clk-imx95-blk-ctl.c | 438 +++++++++++++++++++++
> > > include/dt-bindings/clock/nxp,imx95-clock.h | 32 ++
> > > 9 files changed, 740 insertions(+)
> > > ---
> > > base-commit: c9c32620af65fee2b1ac8390fe1349b33f9d0888
> > > change-id: 20240228-imx95-blk-ctl-9ef8c1fc4c22
> > >
> > > Best regards,
> > > --
> > > Peng Fan <[email protected]>
> > >
> > >
> > >
>
> Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> features
>
> On 24-03-18, Peng Fan wrote:
> > Hi Marco,
> >
> > > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > > features
> > >
> > > Hi Peng,
> > >
> > > thank for the patchset.
> > >
> > > On 24-03-14, Peng Fan (OSS) wrote:
> > > > i.MX95's several MIXes has BLK CTL module which could be used for
> > > > clk settings, QoS settings, Misc settings for a MIX. This patchset
> > > > is to add the clk feature support, including dt-bindings
> > >
> > > I have to ask since there is almost no public documentation
> > > available yet. The
> > > i.MX95 does have an system-controller for managing pinmux settings
> > > and power-domains, right?
> >
> > Yes.
> >
> > If this is the case, why not making use of it via the
> > > standard scmi_pm_domain.c driver?
> >
> > The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff is a
> > mix of clk, qos, module specific things. It is not good for SCMI
> > firmare to handle it.
>
> Currently most of the blk-ctrl users do use the blk-ctrl as power-domain
> consumer, except for the isi and the audio part.
Yes, for i.MX8M.
So as I said above the
> scmi_pm_domain.c should be able to supply this. The audio blk-ctrl could be
> abstracted via the clk-scmi.c driver. The ISI is another topic.
Pengutronix rejected the efforts for putting blk ctrl stuff in ATF for i.MX8M
before. So we take the kernel power domain approach to handle blk ctrl
clk gating.
>
> What you're are going to do here is to put pinctrl etc into SCMI firmware and
> power-control into Linux, which sound to me like an 50/50 approach and
> IMHO is rather sub-optimal.
Now back to i.MX95 which supports function safety.
The SCMI firmware only handle CCM/SRC/GPC for clock/power, it not
handle blk ctrl. The BLK CTRL registers are not only for clk gating, it has
other module specific functions. Moving BLK CTRL to SCMI firmware,
means linux accessing module specific functions needs go through
vendor SCMI protocol. And BLK CTRL stuff is MIX level stuff, it is not
SOC level stuff as CCM which is system critical resource.
(BLK CTLR, I mean non system critical BLK CTRL, such as GPU,VPU,DISP)
The other approach is to let ATF as SCMI server to handle BLK CTRL stuff,
But I not see benefits.
To quote your online available fact sheet:
>
> 8<----------------------------------------------------------
> ENERGY FLEX ARCHITECTURE
>
> The i,MX 95 family is designed to be configurable and scalable, with multiple
> heterogenous processing domains.
> This includes an application domain with up to 6 Arm Cortex A55 cores, a
> high-performance real-time domain with Arm Cortex M7, and low-
> power/safety domain with Arm Cortex M33, each able to access interfaces
> including CAN-FD, 10GbE networking, PCIe Gen 3 x1 interfaces, and
> accelerators such as V2X, ISP, and VPU.
> 8<----------------------------------------------------------
>
> 8<----------------------------------------------------------
> HIGH-PERFORMANCE COMPUTE
> The i.MX 95 family capabilities include a multi-core application domain with
> up to six Arm Cortex(r)-A55 cores, as well as two independent real-time
> domains for safety/low-power, and high-performance real-time use,
> consisting of high-performance Arm Cortex-M7 and Arm Cortex-M33 CPUs,
> combining low-power, real-time, and high-performance processing. The i.MX
> 95 family is designed to enable ISO 26262 ASIL-B and SIL-2 IEC 61508
> compliant platforms, with the safety domain serving as a critical capability for
> many automotive and industrial applications.
> ...
> 8<----------------------------------------------------------
>
> To me this sound like we can turn of the power/clock of an hardware block
> which was assigned to a core running SIL-2 certified software from an non-
> critical core running Linux if we follow that approach. Also the
> SIL-2 software requires the non-critical software to turn on the power of these
> hardware blocks. Is this correct?
Non-critical software not able to turn off power/clock of a critical resource in
safety software domain.
Safety software not require non-safety software to turn on power/clocks.
CCM/SRC/GPC is handled by SCMI firmware, agent w/o safety needs use
SCMI API to request SCMI firmware to enable clock/power for a module.
The SCMI firmware will check whether the agent is allowed to touch
a clock entry or a power entry.
Regards,
Peng.
>
> Regards,
> Marco
>
> > Regards,
> > Peng.
> >
> > >
> > > Regards,
> > > Marco
> > >
> > >
> > >
> > > >
> > > > Signed-off-by: Peng Fan <[email protected]>
> > > > ---
> > > > Changes in v4:
> > > > - Separate binding doc for each modules, I still keep the syscon
> > > > as node name, because the module is not just for clock
> > > > - Pass dt-schema check
> > > > - Update node compatibles
> > > > - Link to v3:
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >
> lore%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C1e1d2c2cea9448b1bc
> 2e08
> > > >
> dc47322ce1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846
> 35280
> > > >
> 23000120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luM
> > > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bcZKZGSM1
> 7Nv0
> > > > Yju6wZu1mSt8GGZH73aAkj9FArP8O0%3D&reserved=0
> > > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v3-0-
> > > 40ceba01a211%40nxp.com&d
> > > >
> > >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > > b3952%7C
> > > >
> > >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969085566
> > > 1%7CUnknow
> > > >
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLC
> > > >
> > >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=M%2B3lDY9BKvW0nHv4mtvi82RA
> > > 9IvYyz72TCbL
> > > > UpiYcG0%3D&reserved=0
> > > >
> > > > Changes in v3:
> > > > - Correct example node compatible string
> > > > - Pass "make ARCH=arm64 DT_CHECKER_FLAGS=-m -j32
> dt_binding_check"
> > > > - Link to v2:
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >
> lore%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C1e1d2c2cea9448b1bc
> 2e08
> > > >
> dc47322ce1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846
> 35280
> > > >
> 23016027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luM
> > > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OTCEsnQm1
> PVPa
> > > > HlXr84xZtmkg1sbtz1TIRFSURLzcPM%3D&reserved=0
> > > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v2-0-
> > > ffb7eefb6dcd%40nxp.com&d
> > > >
> > >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > > b3952%7C
> > > >
> > >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969086560
> > > 2%7CUnknow
> > > >
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLC
> > > >
> > >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4leg49tKhwUMzvD5wlnvgVc7is%2
> > > FGMNvpYr6A
> > > > %2FAf3OU4%3D&reserved=0
> > > >
> > > > Changes in v2:
> > > > - Correct example node compatible string
> > > > - Link to v1:
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >
> lore%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C1e1d2c2cea9448b1bc
> 2e08
> > > >
> dc47322ce1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846
> 35280
> > > >
> 23029152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luM
> > > >
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NRw0LCxEg
> %2F8
> > > > C7WphEWYliUSufjDHQpl1qz58GTZOYxY%3D&reserved=0
> > > > .kernel.org%2Fr%2F20240228-imx95-blk-ctl-v1-0-
> > > 9b5ae3c14d83%40nxp.com&d
> > > >
> > >
> ata=05%7C02%7Cpeng.fan%40nxp.com%7Caad977d7e4f94c750de408dc469
> > > b3952%7C
> > > >
> > >
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63846287969087217
> > > 2%7CUnknow
> > > >
> > >
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> > > WwiLC
> > > >
> > >
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UuD5MVPFgBqwftuXCIXB7SeGyu0
> > > NWPbwY%2Bvy
> > > > ChFLyVA%3D&reserved=0
> > > >
> > > > ---
> > > > Peng Fan (6):
> > > > dt-bindindgs: clock: nxp: support i.MX95 VPU CSR module
> > > > dt-bindindgs: clock: nxp: support i.MX95 Camera CSR module
> > > > dt-bindindgs: clock: nxp: support i.MX95 Display Master CSR module
> > > > dt-bindindgs: clock: nxp: support i.MX95 LVDS CSR module
> > > > dt-bindindgs: clock: nxp: support i.MX95 Display CSR module
> > > > clk: imx: add i.MX95 BLK CTL clk driver
> > > >
> > > > .../bindings/clock/nxp,imx95-camera-csr.yaml | 50 +++
> > > > .../bindings/clock/nxp,imx95-display-csr.yaml | 50 +++
> > > > .../clock/nxp,imx95-display-master-csr.yaml | 62 +++
> > > > .../bindings/clock/nxp,imx95-lvds-csr.yaml | 50 +++
> > > > .../bindings/clock/nxp,imx95-vpu-csr.yaml | 50 +++
> > > > drivers/clk/imx/Kconfig | 7 +
> > > > drivers/clk/imx/Makefile | 1 +
> > > > drivers/clk/imx/clk-imx95-blk-ctl.c | 438
> +++++++++++++++++++++
> > > > include/dt-bindings/clock/nxp,imx95-clock.h | 32 ++
> > > > 9 files changed, 740 insertions(+)
> > > > ---
> > > > base-commit: c9c32620af65fee2b1ac8390fe1349b33f9d0888
> > > > change-id: 20240228-imx95-blk-ctl-9ef8c1fc4c22
> > > >
> > > > Best regards,
> > > > --
> > > > Peng Fan <[email protected]>
> > > >
> > > >
> > > >
> >
> Subject: Re: [PATCH v4 5/6] dt-bindindgs: clock: nxp: support i.MX95 Display
> CSR module
>
> On 14/03/2024 14:25, Peng Fan (OSS) wrote:
> > From: Peng Fan <[email protected]>
> >
> > The DISPLAY_CSR provides control and status of the following:
> > Clock selection for the Display Engines Pixel Interleaver mode
> > selection Pixel Link enables QoS settings for the display controller
> > ArCache and AwCache signals Display Engine plane association
> >
> > This patch is to add the clock features for this module
> >
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> > .../bindings/clock/nxp,imx95-display-csr.yaml | 50
> ++++++++++++++++++++++
> > include/dt-bindings/clock/nxp,imx95-clock.h | 4 ++
> > 2 files changed, 54 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
> > b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.yaml
> > new file mode 100644
> > index 000000000000..9a5e21346b0d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-display-csr.ya
> > +++ ml
> > @@ -0,0 +1,50 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fschemas%2Fclock%2Fnxp%2Cimx95-display-
> csr.yaml%23&data=0
> >
> +5%7C02%7Cpeng.fan%40nxp.com%7C479f8c47bd4d421a669708dc45316f1
> 2%7C686e
> >
> +a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638461325839625184%7
> CUnknown%7
> >
> +CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJX
> >
> +VCI6Mn0%3D%7C0%7C%7C%7C&sdata=rntSlDs8ASXSb3L%2F9ZCzgW%2Bzo
> v2LU9vcTD7
> > +SvjE37Nw%3D&reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7C479f8c47bd4d421a669708dc45316f12%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> +301635%7C0%7C0%7C638461325839637072%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=%2BjYpR8p7IDjRzV39hJhtv8FozALx9HqqLhoFgwBJCm4%3D&reserv
> ed=0
> > +
> > +title: NXP i.MX95 Display Block Control
> > +
> > +maintainers:
> > + - Peng Fan <[email protected]>
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - const: nxp,imx95-display-csr
> > + - const: syscon
>
> Why do you create five different bindings with almost the same contents?
> Do you plan to grow on them, like add more compatibles here? Otherwise all
> this could be in one binding.
The blk ctrls are for different functions.
We may expand the bindings to add more properties for the blk ctrls, but I
am not sure as of now. I could merge them into one binding except
the one with mux-controller if you prefer. Or leave them as is, still
separate binding files.
Thanks,
Peng.
>
> Best regards,
> Krzysztof
On 24-03-18, Peng Fan wrote:
> > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > features
> >
> > On 24-03-18, Peng Fan wrote:
> > > Hi Marco,
> > >
> > > > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > > > features
> > > >
> > > > Hi Peng,
> > > >
> > > > thank for the patchset.
> > > >
> > > > On 24-03-14, Peng Fan (OSS) wrote:
> > > > > i.MX95's several MIXes has BLK CTL module which could be used for
> > > > > clk settings, QoS settings, Misc settings for a MIX. This patchset
> > > > > is to add the clk feature support, including dt-bindings
> > > >
> > > > I have to ask since there is almost no public documentation
> > > > available yet. The
> > > > i.MX95 does have an system-controller for managing pinmux settings
> > > > and power-domains, right?
> > >
> > > Yes.
> > >
> > > If this is the case, why not making use of it via the
> > > > standard scmi_pm_domain.c driver?
> > >
> > > The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff is a
> > > mix of clk, qos, module specific things. It is not good for SCMI
> > > firmare to handle it.
> >
> > Currently most of the blk-ctrl users do use the blk-ctrl as power-domain
> > consumer, except for the isi and the audio part.
>
> Yes, for i.MX8M.
>
> > So as I said above the
> > scmi_pm_domain.c should be able to supply this. The audio blk-ctrl could be
> > abstracted via the clk-scmi.c driver. The ISI is another topic.
>
> Pengutronix rejected the efforts for putting blk ctrl stuff in ATF for i.MX8M
> before. So we take the kernel power domain approach to handle blk ctrl
> clk gating.
AFAIK the problem here was that your proposal had an layering violation
even worse it was an layering inversion since the TF-A (lower layer)
code updated CCM registers which were under control of Linux (upper
layer).
> > What you're are going to do here is to put pinctrl etc into SCMI firmware and
> > power-control into Linux, which sound to me like an 50/50 approach and
> > IMHO is rather sub-optimal.
>
> Now back to i.MX95 which supports function safety.
>
> The SCMI firmware only handle CCM/SRC/GPC for clock/power, it not
> handle blk ctrl.
I know that.
> The BLK CTRL registers are not only for clk gating, it has other
> module specific functions.
I suspected that this is the case for i.MX95 too :/
> Moving BLK CTRL to SCMI firmware, means linux accessing module
> specific functions needs go through vendor SCMI protocol.
Right and here it's a bit complicated to have an proper interface.
Therefore I'm not again the solution of keeping the blk-ctrl within
Linux.
> And BLK CTRL stuff is MIX level stuff, it is not SOC level stuff as
> CCM which is system critical resource.
Hm.. it's still SoC level albeit the area is more limited to specific
functions like HSIO, MEDIA, GPU, ...
> (BLK CTLR, I mean non system critical BLK CTRL, such as GPU,VPU,DISP)
What's system critical is up to the system design but I get your point
that having an safe DISP stack is not going to happen.
> The other approach is to let ATF as SCMI server to handle BLK CTRL stuff,
> But I not see benefits.
How is that any different from putting it into the system-controller
firmware.
> > To quote your online available fact sheet:
> >
> > 8<----------------------------------------------------------
> > ENERGY FLEX ARCHITECTURE
> >
> > The i,MX 95 family is designed to be configurable and scalable, with multiple
> > heterogenous processing domains.
> > This includes an application domain with up to 6 Arm Cortex A55 cores, a
> > high-performance real-time domain with Arm Cortex M7, and low-
> > power/safety domain with Arm Cortex M33, each able to access interfaces
> > including CAN-FD, 10GbE networking, PCIe Gen 3 x1 interfaces, and
> > accelerators such as V2X, ISP, and VPU.
> > 8<----------------------------------------------------------
> >
> > 8<----------------------------------------------------------
> > HIGH-PERFORMANCE COMPUTE
> > The i.MX 95 family capabilities include a multi-core application domain with
> > up to six Arm Cortex(r)-A55 cores, as well as two independent real-time
> > domains for safety/low-power, and high-performance real-time use,
> > consisting of high-performance Arm Cortex-M7 and Arm Cortex-M33 CPUs,
> > combining low-power, real-time, and high-performance processing. The i.MX
> > 95 family is designed to enable ISO 26262 ASIL-B and SIL-2 IEC 61508
> > compliant platforms, with the safety domain serving as a critical capability for
> > many automotive and industrial applications.
> > ...
> > 8<----------------------------------------------------------
> >
> > To me this sound like we can turn of the power/clock of an hardware block
> > which was assigned to a core running SIL-2 certified software from an non-
> > critical core running Linux if we follow that approach. Also the
> > SIL-2 software requires the non-critical software to turn on the power of these
> > hardware blocks. Is this correct?
>
> Non-critical software not able to turn off power/clock of a critical resource in
> safety software domain.
> Safety software not require non-safety software to turn on power/clocks.
Due to lack of documentation I don't know how you implemented this in
HW/SW, also the system-design is telling us which parts should be seen
as safe and which don't. However I get your point, VPUMIX is not going
to be a part of the safe partition albeit it "could" due to complexity.
> CCM/SRC/GPC is handled by SCMI firmware, agent w/o safety needs use
> SCMI API to request SCMI firmware to enable clock/power for a module.
> The SCMI firmware will check whether the agent is allowed to touch
> a clock entry or a power entry.
I got this. I still don't like the 50/50 approach but I also get your
point about the GPR registers which is the only valid argument to me of
not putting the blk-ctrl handling into the system-controller firmware.
Regards,
Marco
On 18/03/2024 13:37, Peng Fan wrote:
>>> +
>>> +maintainers:
>>> + - Peng Fan <[email protected]>
>>> +
>>> +properties:
>>> + compatible:
>>> + items:
>>> + - const: nxp,imx95-display-csr
>>> + - const: syscon
>>
>> Why do you create five different bindings with almost the same contents?
>> Do you plan to grow on them, like add more compatibles here? Otherwise all
>> this could be in one binding.
>
> The blk ctrls are for different functions.
>
> We may expand the bindings to add more properties for the blk ctrls, but I
> am not sure as of now. I could merge them into one binding except
Bindings should be complete...
Best regards,
Krzysztof
> Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> features
>
> On 24-03-18, Peng Fan wrote:
> > > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module clock
> > > features
> > >
> > > On 24-03-18, Peng Fan wrote:
> > > > Hi Marco,
> > > >
> > > > > Subject: Re: [PATCH v4 0/6] Add support i.MX95 BLK CTL module
> > > > > clock features
> > > > >
> > > > > Hi Peng,
> > > > >
> > > > > thank for the patchset.
> > > > >
> > > > > On 24-03-14, Peng Fan (OSS) wrote:
> > > > > > i.MX95's several MIXes has BLK CTL module which could be used
> > > > > > for clk settings, QoS settings, Misc settings for a MIX. This
> > > > > > patchset is to add the clk feature support, including
> > > > > > dt-bindings
> > > > >
> > > > > I have to ask since there is almost no public documentation
> > > > > available yet. The
> > > > > i.MX95 does have an system-controller for managing pinmux
> > > > > settings and power-domains, right?
> > > >
> > > > Yes.
> > > >
> > > > If this is the case, why not making use of it via the
> > > > > standard scmi_pm_domain.c driver?
> > > >
> > > > The SCMI firmware not handle the BLK CTL stuff, but blk ctl stuff
> > > > is a mix of clk, qos, module specific things. It is not good for
> > > > SCMI firmare to handle it.
> > >
> > > Currently most of the blk-ctrl users do use the blk-ctrl as
> > > power-domain consumer, except for the isi and the audio part.
> >
> > Yes, for i.MX8M.
> >
> > > So as I said above the
> > > scmi_pm_domain.c should be able to supply this. The audio blk-ctrl
> > > could be abstracted via the clk-scmi.c driver. The ISI is another topic.
> >
> > Pengutronix rejected the efforts for putting blk ctrl stuff in ATF for
> > i.MX8M before. So we take the kernel power domain approach to handle
> > blk ctrl clk gating.
>
> AFAIK the problem here was that your proposal had an layering violation
> even worse it was an layering inversion since the TF-A (lower layer) code
> updated CCM registers which were under control of Linux (upper layer).
>
> > > What you're are going to do here is to put pinctrl etc into SCMI
> > > firmware and power-control into Linux, which sound to me like an
> > > 50/50 approach and IMHO is rather sub-optimal.
> >
> > Now back to i.MX95 which supports function safety.
> >
> > The SCMI firmware only handle CCM/SRC/GPC for clock/power, it not
> > handle blk ctrl.
>
> I know that.
>
> > The BLK CTRL registers are not only for clk gating, it has other
> > module specific functions.
>
> I suspected that this is the case for i.MX95 too :/
Yes, BLK CTRL is a group of control registers for a MIX, including i.MX95.
>
> > Moving BLK CTRL to SCMI firmware, means linux accessing module
> > specific functions needs go through vendor SCMI protocol.
>
> Right and here it's a bit complicated to have an proper interface.
> Therefore I'm not again the solution of keeping the blk-ctrl within Linux.
>
> > And BLK CTRL stuff is MIX level stuff, it is not SOC level stuff as
> > CCM which is system critical resource.
>
> Hm.. it's still SoC level albeit the area is more limited to specific functions like
> HSIO, MEDIA, GPU, ...
>
> > (BLK CTLR, I mean non system critical BLK CTRL, such as GPU,VPU,DISP)
>
> What's system critical is up to the system design but I get your point that
> having an safe DISP stack is not going to happen.
Right. There is a M7 core runs safety application, there is a system
controller core manage clk/power/pin and etc.
The DISP related BLK CTRL could be directly assigned to M7 core if there is
such usecase.
>
> > The other approach is to let ATF as SCMI server to handle BLK CTRL
> > stuff, But I not see benefits.
>
> How is that any different from putting it into the system-controller firmware.
>
> > > To quote your online available fact sheet:
> > >
> > > 8<----------------------------------------------------------
> > > ENERGY FLEX ARCHITECTURE
> > >
> > > The i,MX 95 family is designed to be configurable and scalable, with
> > > multiple heterogenous processing domains.
> > > This includes an application domain with up to 6 Arm Cortex A55
> > > cores, a high-performance real-time domain with Arm Cortex M7, and
> > > low- power/safety domain with Arm Cortex M33, each able to access
> > > interfaces including CAN-FD, 10GbE networking, PCIe Gen 3 x1
> > > interfaces, and accelerators such as V2X, ISP, and VPU.
> > > 8<----------------------------------------------------------
> > >
> > > 8<----------------------------------------------------------
> > > HIGH-PERFORMANCE COMPUTE
> > > The i.MX 95 family capabilities include a multi-core application
> > > domain with up to six Arm Cortex(r)-A55 cores, as well as two
> > > independent real-time domains for safety/low-power, and
> > > high-performance real-time use, consisting of high-performance Arm
> > > Cortex-M7 and Arm Cortex-M33 CPUs, combining low-power, real-time,
> > > and high-performance processing. The i.MX
> > > 95 family is designed to enable ISO 26262 ASIL-B and SIL-2 IEC 61508
> > > compliant platforms, with the safety domain serving as a critical
> > > capability for many automotive and industrial applications.
> > > ...
> > > 8<----------------------------------------------------------
> > >
> > > To me this sound like we can turn of the power/clock of an hardware
> > > block which was assigned to a core running SIL-2 certified software
> > > from an non- critical core running Linux if we follow that approach.
> > > Also the
> > > SIL-2 software requires the non-critical software to turn on the
> > > power of these hardware blocks. Is this correct?
> >
> > Non-critical software not able to turn off power/clock of a critical
> > resource in safety software domain.
> > Safety software not require non-safety software to turn on power/clocks.
>
> Due to lack of documentation I don't know how you implemented this in
> HW/SW, also the system-design is telling us which parts should be seen as
> safe and which don't. However I get your point, VPUMIX is not going to be a
> part of the safe partition albeit it "could" due to complexity.
If safe function needs VPU feature, VPUMIX could be totally assigned to M7
core through TRDC isolation, not assigned its BLK CTRL to system controller
core.
>
> > CCM/SRC/GPC is handled by SCMI firmware, agent w/o safety needs use
> > SCMI API to request SCMI firmware to enable clock/power for a module.
> > The SCMI firmware will check whether the agent is allowed to touch a
> > clock entry or a power entry.
>
> I got this. I still don't like the 50/50 approach but I also get your point about
> the GPR registers which is the only valid argument to me of not putting the
> blk-ctrl handling into the system-controller firmware.
Thanks,
Peng.
>
> Regards,
> Marco
On 24-03-18, Peng Fan wrote:
> > > > To me this sound like we can turn of the power/clock of an hardware
> > > > block which was assigned to a core running SIL-2 certified software
> > > > from an non- critical core running Linux if we follow that approach.
> > > > Also the
> > > > SIL-2 software requires the non-critical software to turn on the
> > > > power of these hardware blocks. Is this correct?
> > >
> > > Non-critical software not able to turn off power/clock of a critical
> > > resource in safety software domain.
> > > Safety software not require non-safety software to turn on power/clocks.
> >
> > Due to lack of documentation I don't know how you implemented this in
> > HW/SW, also the system-design is telling us which parts should be seen as
> > safe and which don't. However I get your point, VPUMIX is not going to be a
> > part of the safe partition albeit it "could" due to complexity.
>
> If safe function needs VPU feature, VPUMIX could be totally assigned to M7
> core through TRDC isolation, not assigned its BLK CTRL to system controller
> core.
Thanks for the clarification :)
Regards,
Marco