[PATCH 0/3] Add power domain driver support for i.mx8m family

[PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

The i.MX8M family is a set of NXP product focus on delivering
the latest and greatest video and audio experience combining
state-of-the-art media-specific features with high-performance
processing while optimized for lowest power consumption.
i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all
belong to this family.

The GPC module is used to manage the PU power domains' power
on/off. For the whole i.MX8M family, different SoC has differnt
power domain design. the power up sequence has significant difference.
all the power sequence must be guaranteed by SW. Some domains' power
up sequence need to access the SRC module or sub-system specific GPR.
the SRC register & SS's register are not in in the GPC's memory range.

it makes us hard to use the GPCv2 driver to cover all the different
power up requirement. Each time, a new SoC is added, we must modify
the GPCv2 driver to make it resuable for it. a lot of code need to
be added in GPCv2 to support it. we need to access the SRC & SS' GPR,
then the GPCv2 driver can NOT be self-contained. Accessing the non-driver
specific module's register is a bad practice. Although, the GPC module
provided the similar function for PU power domain, but it is not 100%
compatible with GPCv2.

The most important thing is that the GPC & SRC module is a security
critical resource that security permission must be considered when
building the security system. The GPC module is not only used by
PU power domain power on/off. It is also used by the TF-A PSCI code
to do the CPU core power management. the SRC module control the
CPU CORE reset and the CPU reset vector address. if we give the
non-secure world write permission to SRC. System can be easily
induced to malicious code.

This patchset add a more generic power domain driver that give
us the possibility to use one driver to cover the whole i.MX8M
family power domain in kernel side. kernel side doesn't need to
handle the power domain difference anymore, all the sequence can be
abstracted & handled in TF-A side. Most important, We don't need to
care if the GPC & SRC is security protected.

Jacky Bai (3):
  dt-bindings: power: Add power domain binding for i.mx8m family
  soc: imx: Add power domain driver support for i.mx8m family
  arm64: dts: freescale: Add power domain nodes for i.mx8mm

 .../bindings/power/fsl,imx8m-genpd.txt        |  46 ++++
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 103 ++++++++
 drivers/soc/imx/Kconfig                       |   6 +
 drivers/soc/imx/Makefile                      |   1 +
 drivers/soc/imx/imx8m_pm_domains.c            | 224 ++++++++++++++++++
 include/soc/imx/imx_sip.h                     |  12 +
 6 files changed, 392 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/soc/imx/imx_sip.h

-- 
2.21.0

[PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

The i.MX8M family is a set of NXP product focus on delivering
the latest and greatest video and audio experience combining
state-of-the-art media-specific features with high-performance
processing while optimized for lowest power consumption.
i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all
belong to this family.

The GPC module is used to manage the PU power domains' power
on/off. For the whole i.MX8M family, different SoC has differnt
power domain design. the power up sequence has significant difference.
all the power sequence must be guaranteed by SW. Some domains' power
up sequence need to access the SRC module or sub-system specific GPR.
the SRC register & SS's register are not in in the GPC's memory range.

it makes us hard to use the GPCv2 driver to cover all the different
power up requirement. Each time, a new SoC is added, we must modify
the GPCv2 driver to make it resuable for it. a lot of code need to
be added in GPCv2 to support it. we need to access the SRC & SS' GPR,
then the GPCv2 driver can NOT be self-contained. Accessing the non-driver
specific module's register is a bad practice. Although, the GPC module
provided the similar function for PU power domain, but it is not 100%
compatible with GPCv2.

The most important thing is that the GPC & SRC module is a security
critical resource that security permission must be considered when
building the security system. The GPC module is not only used by
PU power domain power on/off. It is also used by the TF-A PSCI code
to do the CPU core power management. the SRC module control the
CPU CORE reset and the CPU reset vector address. if we give the
non-secure world write permission to SRC. System can be easily
induced to malicious code.

This patchset add a more generic power domain driver that give
us the possibility to use one driver to cover the whole i.MX8M
family power domain in kernel side. kernel side doesn't need to
handle the power domain difference anymore, all the sequence can be
abstracted & handled in TF-A side. Most important, We don't need to
care if the GPC & SRC is security protected.

Jacky Bai (3):
  dt-bindings: power: Add power domain binding for i.mx8m family
  soc: imx: Add power domain driver support for i.mx8m family
  arm64: dts: freescale: Add power domain nodes for i.mx8mm

 .../bindings/power/fsl,imx8m-genpd.txt        |  46 ++++
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 103 ++++++++
 drivers/soc/imx/Kconfig                       |   6 +
 drivers/soc/imx/Makefile                      |   1 +
 drivers/soc/imx/imx8m_pm_domains.c            | 224 ++++++++++++++++++
 include/soc/imx/imx_sip.h                     |  12 +
 6 files changed, 392 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/soc/imx/imx_sip.h

-- 
2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/3] dt-bindings: power: Add power domain binding for i.mx8m family

[Jacky Bai]

Add the binding doc of power domain for i.MX8M SOC family.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 .../bindings/power/fsl,imx8m-genpd.txt        | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt

diff --git a/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
new file mode 100644
index 000000000000..a92a7103de38
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
@@ -0,0 +1,46 @@
+Device Tree Bindings for Freescale i.MX8M Generic Power Domain
+==============================================================
+The binding for the i.MX8M Generic power Domain[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+Required properties:
+
+ - compatible: should be of:
+	- "fsl,imx8m-power-domain"
+ - #power-domain-cells: Number of cells in a PM domain Specifier, must be 0
+ - domain-index: should be the domain index number need to pass to TF-A
+ - domain-name: the name of this pm domain
+
+Optional properties:
+ - clocks: a number of phandles to clocks that need to be enabled during
+   domain power-up sequence to ensure reset propagation into devices
+   located inside this power domain
+ - power-supply: Power supply used to power the domain
+ - parent-domains: the phandle to the parent power domain
+
+example:
+	vpu_g1_pd: vpug1-pd {
+		compatible = "fsl,imx8mm-pm-domain";
+		#power-domain-cells = <0>;
+		domain-index = <6>;
+		domain-name = "vpu_g1";
+		parent-domains = <&vpumix_pd>;
+		clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>;
+	};
+
+
+Specifying Power domain for IP modules
+======================================
+
+IP cores belonging to a power domain should contain a 'power-domains'
+property that is a phandle for PGC node representing the domain.
+
+Example of a device that is part of the vpu_g1 power domain:
+	vpu_g1: vpu_g1@38300000 {
+		/* ... */
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "irq_hantro";
+		/* ... */
+		power-domains = <&vpu_g1_pd>;
+	};
-- 
2.21.0

[PATCH 1/3] dt-bindings: power: Add power domain binding for i.mx8m family

[Jacky Bai]

Add the binding doc of power domain for i.MX8M SOC family.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 .../bindings/power/fsl,imx8m-genpd.txt        | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt

diff --git a/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
new file mode 100644
index 000000000000..a92a7103de38
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
@@ -0,0 +1,46 @@
+Device Tree Bindings for Freescale i.MX8M Generic Power Domain
+==============================================================
+The binding for the i.MX8M Generic power Domain[1].
+
+[1] Documentation/devicetree/bindings/power/power_domain.txt
+
+Required properties:
+
+ - compatible: should be of:
+	- "fsl,imx8m-power-domain"
+ - #power-domain-cells: Number of cells in a PM domain Specifier, must be 0
+ - domain-index: should be the domain index number need to pass to TF-A
+ - domain-name: the name of this pm domain
+
+Optional properties:
+ - clocks: a number of phandles to clocks that need to be enabled during
+   domain power-up sequence to ensure reset propagation into devices
+   located inside this power domain
+ - power-supply: Power supply used to power the domain
+ - parent-domains: the phandle to the parent power domain
+
+example:
+	vpu_g1_pd: vpug1-pd {
+		compatible = "fsl,imx8mm-pm-domain";
+		#power-domain-cells = <0>;
+		domain-index = <6>;
+		domain-name = "vpu_g1";
+		parent-domains = <&vpumix_pd>;
+		clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>;
+	};
+
+
+Specifying Power domain for IP modules
+======================================
+
+IP cores belonging to a power domain should contain a 'power-domains'
+property that is a phandle for PGC node representing the domain.
+
+Example of a device that is part of the vpu_g1 power domain:
+	vpu_g1: vpu_g1@38300000 {
+		/* ... */
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "irq_hantro";
+		/* ... */
+		power-domains = <&vpu_g1_pd>;
+	};
-- 
2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/3] soc: imx: Add power domain driver support for i.mx8m family

[Jacky Bai]

The i.MX8M family is a set of NXP product focus on delivering
the latest and greatest video and audio experience combining
state-of-the-art media-specific features with high-performance
processing while optimized for lowest power consumption.

i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all
belong to this family. A GPC module is used to manage all the
PU power domain on/off. But the situation is that the number of
power domains & the power up sequence has significate difference
on those SoCs. Even on the same SoC. The power up sequence still
has big difference. It makes us hard to reuse the GPCv2 driver to
cover the whole i.MX8M family. Each time a new SoC is supported in
the mainline kernel, we need to modify the GPCv2 driver to support
it. We need to add or modify hundred lines of code in worst case.
It is a bad practice for the driver maintainability.

This driver add a more generic power domain driver that the actual
power on/off is done by TF-A code. the abstraction give us the
possibility that using one driver to cover the whole i.MX8M family
in kernel side.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 drivers/soc/imx/Kconfig            |   6 +
 drivers/soc/imx/Makefile           |   1 +
 drivers/soc/imx/imx8m_pm_domains.c | 224 +++++++++++++++++++++++++++++
 include/soc/imx/imx_sip.h          |  12 ++
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/soc/imx/imx_sip.h

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index d80f899d22f9..9a5a9cb77214 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -7,4 +7,10 @@ config IMX_GPCV2_PM_DOMAINS
 	select PM_GENERIC_DOMAINS
 	default y if SOC_IMX7D
 
+config IMX8M_PM_DOMAINS
+	bool "i.MX8M PM domains"
+	depends on ARCH_MXC || (COMPILE_TEST && OF)
+	depends on PM
+	select PM_GENERIC_DOMAINS
+
 endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 506a6f3c2b9b..627a54f228e5 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
+obj-$(CONFIG_IMX8M_PM_DOMAINS) += imx8m_pm_domains.o
diff --git a/drivers/soc/imx/imx8m_pm_domains.c b/drivers/soc/imx/imx8m_pm_domains.c
new file mode 100644
index 000000000000..ce06a059eaaa
--- /dev/null
+++ b/drivers/soc/imx/imx8m_pm_domains.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regulator/consumer.h>
+
+#include <soc/imx/imx_sip.h>
+
+#define MAX_CLK_NUM	6
+#define to_imx8m_pm_domain(_genpd) container_of(_genpd, struct imx8m_pm_domain, pd)
+
+
+struct imx8m_pm_domain {
+	struct device *dev;
+	struct generic_pm_domain pd;
+	u32 domain_index;
+	struct clk *clk[MAX_CLK_NUM];
+	unsigned int num_clks;
+	struct regulator *reg;
+};
+
+enum imx8m_pm_domain_state {
+	PD_STATE_OFF,
+	PD_STATE_ON,
+};
+
+static DEFINE_MUTEX(gpc_pd_mutex);
+
+static int imx8m_pd_power_on(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	/* power on the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_enable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power up the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* enable the necessary clks needed by the power domain */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_prepare_enable(domain->clk[index]);
+	}
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_ON, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	return 0;
+}
+
+static int imx8m_pd_power_off(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_OFF, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	/* power off the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_disable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power off the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* disable clks when power domain is off */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_disable_unprepare(domain->clk[index]);
+	}
+
+	return ret;
+};
+
+static int imx8m_pd_get_clocks(struct imx8m_pm_domain *domain)
+{
+	int i, ret;
+
+	for (i = 0; ; i++) {
+		struct clk *clk = of_clk_get(domain->dev->of_node, i);
+		if (IS_ERR(clk))
+			break;
+		if (i >= MAX_CLK_NUM) {
+			dev_err(domain->dev, "more than %d clocks\n",
+				MAX_CLK_NUM);
+			ret = -EINVAL;
+			goto clk_err;
+		}
+		domain->clk[i] = clk;
+	}
+	domain->num_clks = i;
+
+	return 0;
+
+clk_err:
+	while (i--)
+		clk_put(domain->clk[i]);
+
+	return ret;
+}
+
+static void imx8m_pd_put_clocks(struct imx8m_pm_domain *domain)
+{
+	int i;
+
+	for (i = domain->num_clks - 1; i >= 0; i--)
+		clk_put(domain->clk[i]);
+}
+
+static const struct of_device_id imx8m_pm_domain_ids[] = {
+	{.compatible = "fsl,imx8m-pm-domain"},
+	{},
+};
+
+static int imx8m_pm_domain_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8m_pm_domain *domain;
+	struct of_phandle_args parent, child;
+	int ret;
+
+	domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
+	if (!domain)
+		return -ENOMEM;
+
+	child.np = np;
+	domain->dev = dev;
+
+	ret = of_property_read_string(np, "domain-name", &domain->pd.name);
+	if (ret) {
+		dev_err(dev, "failed to get the domain name\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(np, "domain-index", &domain->domain_index);
+	if (ret) {
+		dev_err(dev, "failed to get the domain index\n");
+		return -EINVAL;
+	}
+
+	domain->reg = devm_regulator_get_optional(dev, "power");
+	if (IS_ERR(domain->reg)) {
+		if (PTR_ERR(domain->reg) != -ENODEV) {
+			if (PTR_ERR(domain->reg) != -EPROBE_DEFER)
+				dev_err(dev, "failed to get domain's regulator\n");
+			return PTR_ERR(domain->reg);
+		}
+	}
+
+	ret = imx8m_pd_get_clocks(domain);
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get domain's clocks\n");
+		return ret;
+	}
+
+	domain->pd.power_off = imx8m_pd_power_off;
+	domain->pd.power_on = imx8m_pd_power_on;
+
+	pm_genpd_init(&domain->pd, NULL, true);
+
+	ret = of_genpd_add_provider_simple(np, &domain->pd);
+	if (ret) {
+		dev_err(dev, "failed to add the domain provider\n");
+		pm_genpd_remove(&domain->pd);
+		imx8m_pd_put_clocks(domain);
+		return ret;
+	}
+
+	/* add it as subdomain if necessary */
+	if (!of_parse_phandle_with_args(np, "parent-domains",
+			"#power-domain-cells", 0, &parent)) {
+		ret = of_genpd_add_subdomain(&parent, &child);
+		of_node_put(parent.np);
+
+		if (ret < 0) {
+			dev_dbg(dev, "failed to add the subdomain: %s: %d",
+				domain->pd.name, ret);
+			of_genpd_del_provider(np);
+			pm_genpd_remove(&domain->pd);
+			imx8m_pd_put_clocks(domain);
+			return driver_deferred_probe_check_state(dev);
+		}
+	}
+
+	return 0;
+}
+
+static struct platform_driver imx8m_pm_domain_driver = {
+	.driver = {
+		.name	= "imx8m_pm_domain",
+		.owner	= THIS_MODULE,
+		.of_match_table = imx8m_pm_domain_ids,
+	},
+	.probe = imx8m_pm_domain_probe,
+};
+module_platform_driver(imx8m_pm_domain_driver);
+
+MODULE_AUTHOR("NXP");
+MODULE_DESCRIPTION("NXP i.MX8M power domain driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/imx/imx_sip.h b/include/soc/imx/imx_sip.h
new file mode 100644
index 000000000000..6b96b33c870e
--- /dev/null
+++ b/include/soc/imx/imx_sip.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2019 NXP
+ */
+
+#ifndef __IMX_SIP_H__
+#define __IMX_SIP_H__
+
+#define IMX_SIP_GPC			0xC2000000
+#define IMX_SIP_CONFIG_GPC_PM_DOMAIN	0x03
+
+#endif /* __IMX_SIP_H__ */
-- 
2.21.0

[PATCH 2/3] soc: imx: Add power domain driver support for i.mx8m family

[Jacky Bai]

The i.MX8M family is a set of NXP product focus on delivering
the latest and greatest video and audio experience combining
state-of-the-art media-specific features with high-performance
processing while optimized for lowest power consumption.

i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all
belong to this family. A GPC module is used to manage all the
PU power domain on/off. But the situation is that the number of
power domains & the power up sequence has significate difference
on those SoCs. Even on the same SoC. The power up sequence still
has big difference. It makes us hard to reuse the GPCv2 driver to
cover the whole i.MX8M family. Each time a new SoC is supported in
the mainline kernel, we need to modify the GPCv2 driver to support
it. We need to add or modify hundred lines of code in worst case.
It is a bad practice for the driver maintainability.

This driver add a more generic power domain driver that the actual
power on/off is done by TF-A code. the abstraction give us the
possibility that using one driver to cover the whole i.MX8M family
in kernel side.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 drivers/soc/imx/Kconfig            |   6 +
 drivers/soc/imx/Makefile           |   1 +
 drivers/soc/imx/imx8m_pm_domains.c | 224 +++++++++++++++++++++++++++++
 include/soc/imx/imx_sip.h          |  12 ++
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
 create mode 100644 include/soc/imx/imx_sip.h

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index d80f899d22f9..9a5a9cb77214 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -7,4 +7,10 @@ config IMX_GPCV2_PM_DOMAINS
 	select PM_GENERIC_DOMAINS
 	default y if SOC_IMX7D
 
+config IMX8M_PM_DOMAINS
+	bool "i.MX8M PM domains"
+	depends on ARCH_MXC || (COMPILE_TEST && OF)
+	depends on PM
+	select PM_GENERIC_DOMAINS
+
 endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 506a6f3c2b9b..627a54f228e5 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
+obj-$(CONFIG_IMX8M_PM_DOMAINS) += imx8m_pm_domains.o
diff --git a/drivers/soc/imx/imx8m_pm_domains.c b/drivers/soc/imx/imx8m_pm_domains.c
new file mode 100644
index 000000000000..ce06a059eaaa
--- /dev/null
+++ b/drivers/soc/imx/imx8m_pm_domains.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regulator/consumer.h>
+
+#include <soc/imx/imx_sip.h>
+
+#define MAX_CLK_NUM	6
+#define to_imx8m_pm_domain(_genpd) container_of(_genpd, struct imx8m_pm_domain, pd)
+
+
+struct imx8m_pm_domain {
+	struct device *dev;
+	struct generic_pm_domain pd;
+	u32 domain_index;
+	struct clk *clk[MAX_CLK_NUM];
+	unsigned int num_clks;
+	struct regulator *reg;
+};
+
+enum imx8m_pm_domain_state {
+	PD_STATE_OFF,
+	PD_STATE_ON,
+};
+
+static DEFINE_MUTEX(gpc_pd_mutex);
+
+static int imx8m_pd_power_on(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	/* power on the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_enable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power up the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* enable the necessary clks needed by the power domain */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_prepare_enable(domain->clk[index]);
+	}
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_ON, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	return 0;
+}
+
+static int imx8m_pd_power_off(struct generic_pm_domain *genpd)
+{
+	struct imx8m_pm_domain *domain = to_imx8m_pm_domain(genpd);
+	struct arm_smccc_res res;
+	int index, ret = 0;
+
+	mutex_lock(&gpc_pd_mutex);
+	arm_smccc_smc(IMX_SIP_GPC, IMX_SIP_CONFIG_GPC_PM_DOMAIN, domain->domain_index,
+		      PD_STATE_OFF, 0, 0, 0, 0, &res);
+	mutex_unlock(&gpc_pd_mutex);
+
+	/* power off the external supply */
+	if (!IS_ERR(domain->reg)) {
+		ret = regulator_disable(domain->reg);
+		if (ret) {
+			dev_warn(domain->dev, "failed to power off the reg%d\n", ret);
+			return ret;
+		}
+	}
+
+	/* disable clks when power domain is off */
+	if (domain->num_clks) {
+		for (index = 0; index < domain->num_clks; index++)
+			clk_disable_unprepare(domain->clk[index]);
+	}
+
+	return ret;
+};
+
+static int imx8m_pd_get_clocks(struct imx8m_pm_domain *domain)
+{
+	int i, ret;
+
+	for (i = 0; ; i++) {
+		struct clk *clk = of_clk_get(domain->dev->of_node, i);
+		if (IS_ERR(clk))
+			break;
+		if (i >= MAX_CLK_NUM) {
+			dev_err(domain->dev, "more than %d clocks\n",
+				MAX_CLK_NUM);
+			ret = -EINVAL;
+			goto clk_err;
+		}
+		domain->clk[i] = clk;
+	}
+	domain->num_clks = i;
+
+	return 0;
+
+clk_err:
+	while (i--)
+		clk_put(domain->clk[i]);
+
+	return ret;
+}
+
+static void imx8m_pd_put_clocks(struct imx8m_pm_domain *domain)
+{
+	int i;
+
+	for (i = domain->num_clks - 1; i >= 0; i--)
+		clk_put(domain->clk[i]);
+}
+
+static const struct of_device_id imx8m_pm_domain_ids[] = {
+	{.compatible = "fsl,imx8m-pm-domain"},
+	{},
+};
+
+static int imx8m_pm_domain_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct imx8m_pm_domain *domain;
+	struct of_phandle_args parent, child;
+	int ret;
+
+	domain = devm_kzalloc(dev, sizeof(*domain), GFP_KERNEL);
+	if (!domain)
+		return -ENOMEM;
+
+	child.np = np;
+	domain->dev = dev;
+
+	ret = of_property_read_string(np, "domain-name", &domain->pd.name);
+	if (ret) {
+		dev_err(dev, "failed to get the domain name\n");
+		return -EINVAL;
+	}
+
+	ret = of_property_read_u32(np, "domain-index", &domain->domain_index);
+	if (ret) {
+		dev_err(dev, "failed to get the domain index\n");
+		return -EINVAL;
+	}
+
+	domain->reg = devm_regulator_get_optional(dev, "power");
+	if (IS_ERR(domain->reg)) {
+		if (PTR_ERR(domain->reg) != -ENODEV) {
+			if (PTR_ERR(domain->reg) != -EPROBE_DEFER)
+				dev_err(dev, "failed to get domain's regulator\n");
+			return PTR_ERR(domain->reg);
+		}
+	}
+
+	ret = imx8m_pd_get_clocks(domain);
+	if (ret) {
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get domain's clocks\n");
+		return ret;
+	}
+
+	domain->pd.power_off = imx8m_pd_power_off;
+	domain->pd.power_on = imx8m_pd_power_on;
+
+	pm_genpd_init(&domain->pd, NULL, true);
+
+	ret = of_genpd_add_provider_simple(np, &domain->pd);
+	if (ret) {
+		dev_err(dev, "failed to add the domain provider\n");
+		pm_genpd_remove(&domain->pd);
+		imx8m_pd_put_clocks(domain);
+		return ret;
+	}
+
+	/* add it as subdomain if necessary */
+	if (!of_parse_phandle_with_args(np, "parent-domains",
+			"#power-domain-cells", 0, &parent)) {
+		ret = of_genpd_add_subdomain(&parent, &child);
+		of_node_put(parent.np);
+
+		if (ret < 0) {
+			dev_dbg(dev, "failed to add the subdomain: %s: %d",
+				domain->pd.name, ret);
+			of_genpd_del_provider(np);
+			pm_genpd_remove(&domain->pd);
+			imx8m_pd_put_clocks(domain);
+			return driver_deferred_probe_check_state(dev);
+		}
+	}
+
+	return 0;
+}
+
+static struct platform_driver imx8m_pm_domain_driver = {
+	.driver = {
+		.name	= "imx8m_pm_domain",
+		.owner	= THIS_MODULE,
+		.of_match_table = imx8m_pm_domain_ids,
+	},
+	.probe = imx8m_pm_domain_probe,
+};
+module_platform_driver(imx8m_pm_domain_driver);
+
+MODULE_AUTHOR("NXP");
+MODULE_DESCRIPTION("NXP i.MX8M power domain driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/imx/imx_sip.h b/include/soc/imx/imx_sip.h
new file mode 100644
index 000000000000..6b96b33c870e
--- /dev/null
+++ b/include/soc/imx/imx_sip.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2019 NXP
+ */
+
+#ifndef __IMX_SIP_H__
+#define __IMX_SIP_H__
+
+#define IMX_SIP_GPC			0xC2000000
+#define IMX_SIP_CONFIG_GPC_PM_DOMAIN	0x03
+
+#endif /* __IMX_SIP_H__ */
-- 
2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] arm64: dts: freescale: Add power domain nodes for i.mx8mm

[Jacky Bai]

Add the power domain nodes for i.MX8MM.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 103 ++++++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index de3498c2dd44..49af5181e17f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -149,6 +149,109 @@
 		interrupt-affinity = <&A53_0>, <&A53_1>, <&A53_2>, <&A53_3>;
 	};
 
+	power-domains {
+		compatible = "simple-bus";
+		/* HSIO SS */
+		hsiomix_pd: hsiomix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <0>;
+			domain-name = "hsiomix";
+			clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
+		};
+
+		pcie_pd: pcie-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <1>;
+			domain-name = "pcie";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		usb_otg1_pd: usbotg1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <2>;
+			domain-name = "usb_otg1";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		usb_otg2_pd: usbotg2-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <3>;
+			domain-name = "usb_otg2";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		/* GPU SS */
+		gpumix_pd: gpumix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <4>;
+			domain-name = "gpumix";
+			clocks = <&clk IMX8MM_CLK_GPU_BUS_ROOT>,
+				 <&clk IMX8MM_CLK_GPU_AHB>,
+				 <&clk IMX8MM_CLK_GPU2D_ROOT>,
+				 <&clk IMX8MM_CLK_GPU3D_ROOT>;
+		};
+
+		/* VPU SS */
+		vpumix_pd: vpumix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <5>;
+			domain-name = "vpumix";
+			clocks = <&clk IMX8MM_CLK_VPU_DEC_ROOT>;
+		};
+
+		vpu_g1_pd: vpug1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <6>;
+			domain-name = "vpu_g1";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>;
+		};
+
+		vpu_g2_pd: vpug2-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <7>;
+			domain-name = "vpu_g2";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_G2_ROOT>;
+		};
+
+		vpu_h1_pd: vpuh1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <8>;
+			domain-name = "vpu_h1";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_H1_ROOT>;
+		};
+
+		/* DISP SS */
+		dispmix_pd: dispmix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <9>;
+			domain-name = "dispmix";
+			clocks = <&clk IMX8MM_CLK_DISP_ROOT>,
+				 <&clk IMX8MM_CLK_DISP_AXI_ROOT>,
+				 <&clk IMX8MM_CLK_DISP_APB_ROOT>;
+		};
+
+		mipi_pd: mipi-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <10>;
+			domain-name = "mipi";
+			parent-domains = <&dispmix_pd>;
+		};
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Secure */
-- 
2.21.0

[PATCH 3/3] arm64: dts: freescale: Add power domain nodes for i.mx8mm

[Jacky Bai]

Add the power domain nodes for i.MX8MM.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 103 ++++++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index de3498c2dd44..49af5181e17f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -149,6 +149,109 @@
 		interrupt-affinity = <&A53_0>, <&A53_1>, <&A53_2>, <&A53_3>;
 	};
 
+	power-domains {
+		compatible = "simple-bus";
+		/* HSIO SS */
+		hsiomix_pd: hsiomix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <0>;
+			domain-name = "hsiomix";
+			clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
+		};
+
+		pcie_pd: pcie-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <1>;
+			domain-name = "pcie";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		usb_otg1_pd: usbotg1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <2>;
+			domain-name = "usb_otg1";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		usb_otg2_pd: usbotg2-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <3>;
+			domain-name = "usb_otg2";
+			parent-domains = <&hsiomix_pd>;
+		};
+
+		/* GPU SS */
+		gpumix_pd: gpumix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <4>;
+			domain-name = "gpumix";
+			clocks = <&clk IMX8MM_CLK_GPU_BUS_ROOT>,
+				 <&clk IMX8MM_CLK_GPU_AHB>,
+				 <&clk IMX8MM_CLK_GPU2D_ROOT>,
+				 <&clk IMX8MM_CLK_GPU3D_ROOT>;
+		};
+
+		/* VPU SS */
+		vpumix_pd: vpumix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <5>;
+			domain-name = "vpumix";
+			clocks = <&clk IMX8MM_CLK_VPU_DEC_ROOT>;
+		};
+
+		vpu_g1_pd: vpug1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <6>;
+			domain-name = "vpu_g1";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_G1_ROOT>;
+		};
+
+		vpu_g2_pd: vpug2-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <7>;
+			domain-name = "vpu_g2";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_G2_ROOT>;
+		};
+
+		vpu_h1_pd: vpuh1-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <8>;
+			domain-name = "vpu_h1";
+			parent-domains = <&vpumix_pd>;
+			clocks = <&clk IMX8MM_CLK_VPU_H1_ROOT>;
+		};
+
+		/* DISP SS */
+		dispmix_pd: dispmix-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <9>;
+			domain-name = "dispmix";
+			clocks = <&clk IMX8MM_CLK_DISP_ROOT>,
+				 <&clk IMX8MM_CLK_DISP_AXI_ROOT>,
+				 <&clk IMX8MM_CLK_DISP_APB_ROOT>;
+		};
+
+		mipi_pd: mipi-pd {
+			compatible = "fsl,imx8m-pm-domain";
+			#power-domain-cells = <0>;
+			domain-index = <10>;
+			domain-name = "mipi";
+			parent-domains = <&dispmix_pd>;
+		};
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Secure */
-- 
2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Aisheng Dong]

> From: Jacky Bai
> Sent: Wednesday, April 17, 2019 1:27 PM
> 
> The i.MX8M family is a set of NXP product focus on delivering the latest and
> greatest video and audio experience combining state-of-the-art media-specific
> features with high-performance processing while optimized for lowest power
> consumption.
> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> this family.
> 
> The GPC module is used to manage the PU power domains' power on/off. For
> the whole i.MX8M family, different SoC has differnt power domain design. the
> power up sequence has significant difference.
> all the power sequence must be guaranteed by SW. Some domains' power up
> sequence need to access the SRC module or sub-system specific GPR.
> the SRC register & SS's register are not in in the GPC's memory range.
> 
> it makes us hard to use the GPCv2 driver to cover all the different power up
> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
> self-contained. Accessing the non-driver specific module's register is a bad
> practice. Although, the GPC module provided the similar function for PU power
> domain, but it is not 100% compatible with GPCv2.
> 
> The most important thing is that the GPC & SRC module is a security critical
> resource that security permission must be considered when building the
> security system. The GPC module is not only used by PU power domain power
> on/off. It is also used by the TF-A PSCI code to do the CPU core power
> management. the SRC module control the CPU CORE reset and the CPU reset
> vector address. if we give the non-secure world write permission to SRC.
> System can be easily induced to malicious code.
> 

Considering the security issue, it looks to me a right direction to move GPC
power handling into ATF.
It also helps build a more generic driver and ease other OS integration
needed by customers (e.g. QNX, Win10).

Lucas,
How do you think of it?

Regards
Dong Aisheng

> This patchset add a more generic power domain driver that give us the
> possibility to use one driver to cover the whole i.MX8M family power domain
> in kernel side. kernel side doesn't need to handle the power domain difference
> anymore, all the sequence can be abstracted & handled in TF-A side. Most
> important, We don't need to care if the GPC & SRC is security protected.
> 
> Jacky Bai (3):
>   dt-bindings: power: Add power domain binding for i.mx8m family
>   soc: imx: Add power domain driver support for i.mx8m family
>   arm64: dts: freescale: Add power domain nodes for i.mx8mm
> 
>  .../bindings/power/fsl,imx8m-genpd.txt        |  46 ++++
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 103 ++++++++
>  drivers/soc/imx/Kconfig                       |   6 +
>  drivers/soc/imx/Makefile                      |   1 +
>  drivers/soc/imx/imx8m_pm_domains.c            | 224
> ++++++++++++++++++
>  include/soc/imx/imx_sip.h                     |  12 +
>  6 files changed, 392 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
>  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
>  create mode 100644 include/soc/imx/imx_sip.h
> 
> --
> 2.21.0

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Aisheng Dong]

> From: Jacky Bai
> Sent: Wednesday, April 17, 2019 1:27 PM
> 
> The i.MX8M family is a set of NXP product focus on delivering the latest and
> greatest video and audio experience combining state-of-the-art media-specific
> features with high-performance processing while optimized for lowest power
> consumption.
> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> this family.
> 
> The GPC module is used to manage the PU power domains' power on/off. For
> the whole i.MX8M family, different SoC has differnt power domain design. the
> power up sequence has significant difference.
> all the power sequence must be guaranteed by SW. Some domains' power up
> sequence need to access the SRC module or sub-system specific GPR.
> the SRC register & SS's register are not in in the GPC's memory range.
> 
> it makes us hard to use the GPCv2 driver to cover all the different power up
> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
> self-contained. Accessing the non-driver specific module's register is a bad
> practice. Although, the GPC module provided the similar function for PU power
> domain, but it is not 100% compatible with GPCv2.
> 
> The most important thing is that the GPC & SRC module is a security critical
> resource that security permission must be considered when building the
> security system. The GPC module is not only used by PU power domain power
> on/off. It is also used by the TF-A PSCI code to do the CPU core power
> management. the SRC module control the CPU CORE reset and the CPU reset
> vector address. if we give the non-secure world write permission to SRC.
> System can be easily induced to malicious code.
> 

Considering the security issue, it looks to me a right direction to move GPC
power handling into ATF.
It also helps build a more generic driver and ease other OS integration
needed by customers (e.g. QNX, Win10).

Lucas,
How do you think of it?

Regards
Dong Aisheng

> This patchset add a more generic power domain driver that give us the
> possibility to use one driver to cover the whole i.MX8M family power domain
> in kernel side. kernel side doesn't need to handle the power domain difference
> anymore, all the sequence can be abstracted & handled in TF-A side. Most
> important, We don't need to care if the GPC & SRC is security protected.
> 
> Jacky Bai (3):
>   dt-bindings: power: Add power domain binding for i.mx8m family
>   soc: imx: Add power domain driver support for i.mx8m family
>   arm64: dts: freescale: Add power domain nodes for i.mx8mm
> 
>  .../bindings/power/fsl,imx8m-genpd.txt        |  46 ++++
>  arch/arm64/boot/dts/freescale/imx8mm.dtsi     | 103 ++++++++
>  drivers/soc/imx/Kconfig                       |   6 +
>  drivers/soc/imx/Makefile                      |   1 +
>  drivers/soc/imx/imx8m_pm_domains.c            | 224
> ++++++++++++++++++
>  include/soc/imx/imx_sip.h                     |  12 +
>  6 files changed, 392 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt
>  create mode 100644 drivers/soc/imx/imx8m_pm_domains.c
>  create mode 100644 include/soc/imx/imx_sip.h
> 
> --
> 2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> > From: Jacky Bai
> > Sent: Wednesday, April 17, 2019 1:27 PM
> > 
> > The i.MX8M family is a set of NXP product focus on delivering the latest and
> > greatest video and audio experience combining state-of-the-art media-specific
> > features with high-performance processing while optimized for lowest power
> > consumption.
> > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> > this family.
> > 
> > The GPC module is used to manage the PU power domains' power on/off. For
> > the whole i.MX8M family, different SoC has differnt power domain design. the
> > power up sequence has significant difference.
> > all the power sequence must be guaranteed by SW. Some domains' power up
> > sequence need to access the SRC module or sub-system specific GPR.
> > the SRC register & SS's register are not in in the GPC's memory range.
> > 
> > it makes us hard to use the GPCv2 driver to cover all the different power up
> > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
> > to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
> > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
> > self-contained. Accessing the non-driver specific module's register is a bad
> > practice. Although, the GPC module provided the similar function for PU power
> > domain, but it is not 100% compatible with GPCv2.
> > 
> > The most important thing is that the GPC & SRC module is a security critical
> > resource that security permission must be considered when building the
> > security system. The GPC module is not only used by PU power domain power
> > on/off. It is also used by the TF-A PSCI code to do the CPU core power
> > management. the SRC module control the CPU CORE reset and the CPU reset
> > vector address. if we give the non-secure world write permission to SRC.
> > System can be easily induced to malicious code.
> > 
> 
> Considering the security issue, it looks to me a right direction to move GPC
> power handling into ATF.
> It also helps build a more generic driver and ease other OS integration
> needed by customers (e.g. QNX, Win10).
> 
> Lucas,
> How do you think of it?

I don't yet buy the security argument. There are many more shared parts
on the SoC, like the clock controller, that would need to be taken away
from the non-secure world if one would want to run an untrusted OS
kernel on a i.MX8M system.

To properly implement security on any i.MX8M based system the firmware
would need to grow something like a full ARM SCPI implementation, so
all shared critical peripherals are solely under firmware control.

I agree that it might make sense to move some parts into the firmware
and have much simpler OS level drivers, but I don't agree on the
implementation direction taken here. Growing custom PSCI extension
interfaces will only get us so far, without solving the system security
issue in a holistic way. It is my strong believe that only a complete
rearchitecture of the OS support on top of a ARM SCPI firmware
interface can solve this properly.

Regards,
Lucas

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> > From: Jacky Bai
> > Sent: Wednesday, April 17, 2019 1:27 PM
> > 
> > The i.MX8M family is a set of NXP product focus on delivering the latest and
> > greatest video and audio experience combining state-of-the-art media-specific
> > features with high-performance processing while optimized for lowest power
> > consumption.
> > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> > this family.
> > 
> > The GPC module is used to manage the PU power domains' power on/off. For
> > the whole i.MX8M family, different SoC has differnt power domain design. the
> > power up sequence has significant difference.
> > all the power sequence must be guaranteed by SW. Some domains' power up
> > sequence need to access the SRC module or sub-system specific GPR.
> > the SRC register & SS's register are not in in the GPC's memory range.
> > 
> > it makes us hard to use the GPCv2 driver to cover all the different power up
> > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
> > to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
> > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
> > self-contained. Accessing the non-driver specific module's register is a bad
> > practice. Although, the GPC module provided the similar function for PU power
> > domain, but it is not 100% compatible with GPCv2.
> > 
> > The most important thing is that the GPC & SRC module is a security critical
> > resource that security permission must be considered when building the
> > security system. The GPC module is not only used by PU power domain power
> > on/off. It is also used by the TF-A PSCI code to do the CPU core power
> > management. the SRC module control the CPU CORE reset and the CPU reset
> > vector address. if we give the non-secure world write permission to SRC.
> > System can be easily induced to malicious code.
> > 
> 
> Considering the security issue, it looks to me a right direction to move GPC
> power handling into ATF.
> It also helps build a more generic driver and ease other OS integration
> needed by customers (e.g. QNX, Win10).
> 
> Lucas,
> How do you think of it?

I don't yet buy the security argument. There are many more shared parts
on the SoC, like the clock controller, that would need to be taken away
from the non-secure world if one would want to run an untrusted OS
kernel on a i.MX8M system.

To properly implement security on any i.MX8M based system the firmware
would need to grow something like a full ARM SCPI implementation, so
all shared critical peripherals are solely under firmware control.

I agree that it might make sense to move some parts into the firmware
and have much simpler OS level drivers, but I don't agree on the
implementation direction taken here. Growing custom PSCI extension
interfaces will only get us so far, without solving the system security
issue in a holistic way. It is my strong believe that only a complete
rearchitecture of the OS support on top of a ARM SCPI firmware
interface can solve this properly.

Regards,
Lucas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 4/17/2019 3:13 PM, Lucas Stach wrote:
> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
>>> From: Jacky Bai
>>> Sent: Wednesday, April 17, 2019 1:27 PM
>>>
>>> The i.MX8M family is a set of NXP product focus on delivering the latest and
>>> greatest video and audio experience combining state-of-the-art media-specific
>>> features with high-performance processing while optimized for lowest power
>>> consumption.
>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
>>> this family.
>>>
>>> The GPC module is used to manage the PU power domains' power on/off. For
>>> the whole i.MX8M family, different SoC has differnt power domain design. the
>>> power up sequence has significant difference.
>>> all the power sequence must be guaranteed by SW. Some domains' power up
>>> sequence need to access the SRC module or sub-system specific GPR.
>>> the SRC register & SS's register are not in in the GPC's memory range.
>>>
>>> it makes us hard to use the GPCv2 driver to cover all the different power up
>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
>>> self-contained. Accessing the non-driver specific module's register is a bad
>>> practice. Although, the GPC module provided the similar function for PU power
>>> domain, but it is not 100% compatible with GPCv2.
>>>
>>> The most important thing is that the GPC & SRC module is a security critical
>>> resource that security permission must be considered when building the
>>> security system. The GPC module is not only used by PU power domain power
>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power
>>> management. the SRC module control the CPU CORE reset and the CPU reset
>>> vector address. if we give the non-secure world write permission to SRC.
>>> System can be easily induced to malicious code.
>>
>> Considering the security issue, it looks to me a right direction to move GPC
>> power handling into ATF.
>> It also helps build a more generic driver and ease other OS integration
>> needed by customers (e.g. QNX, Win10).
>>
>> Lucas,
>> How do you think of it?
> 
> I don't yet buy the security argument. There are many more shared parts
> on the SoC, like the clock controller, that would need to be taken away
> from the non-secure world if one would want to run an untrusted OS
> kernel on a i.MX8M system.
> 
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so
> all shared critical peripherals are solely under firmware control.

It might be possible to rework this to use some form of SCMI-over-SMC 
instead of vendor-specific SMCCC SIP calls

+SCMI maintainer

> I agree that it might make sense to move some parts into the firmware
> and have much simpler OS level drivers, but I don't agree on the
> implementation direction taken here. Growing custom PSCI extension
> interfaces will only get us so far, without solving the system security
> issue in a holistic way. It is my strong believe that only a complete
> rearchitecture of the OS support on top of a ARM SCPI firmware
> interface can solve this properly.
Hiding everything critical for security (especially CCM) behind a SCMI 
interface would be a large amount of work but introducing SCMI 
incrementally (starting with imx8mm power) would be useful by itself 
because it simplifies OS implementation.

Many at NXP have attempted to evaluate SCMI and their conclusion has 
always been that "many extensions are required".

--
Regards,
Leonard

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 4/17/2019 3:13 PM, Lucas Stach wrote:
> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
>>> From: Jacky Bai
>>> Sent: Wednesday, April 17, 2019 1:27 PM
>>>
>>> The i.MX8M family is a set of NXP product focus on delivering the latest and
>>> greatest video and audio experience combining state-of-the-art media-specific
>>> features with high-performance processing while optimized for lowest power
>>> consumption.
>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
>>> this family.
>>>
>>> The GPC module is used to manage the PU power domains' power on/off. For
>>> the whole i.MX8M family, different SoC has differnt power domain design. the
>>> power up sequence has significant difference.
>>> all the power sequence must be guaranteed by SW. Some domains' power up
>>> sequence need to access the SRC module or sub-system specific GPR.
>>> the SRC register & SS's register are not in in the GPC's memory range.
>>>
>>> it makes us hard to use the GPCv2 driver to cover all the different power up
>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
>>> self-contained. Accessing the non-driver specific module's register is a bad
>>> practice. Although, the GPC module provided the similar function for PU power
>>> domain, but it is not 100% compatible with GPCv2.
>>>
>>> The most important thing is that the GPC & SRC module is a security critical
>>> resource that security permission must be considered when building the
>>> security system. The GPC module is not only used by PU power domain power
>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power
>>> management. the SRC module control the CPU CORE reset and the CPU reset
>>> vector address. if we give the non-secure world write permission to SRC.
>>> System can be easily induced to malicious code.
>>
>> Considering the security issue, it looks to me a right direction to move GPC
>> power handling into ATF.
>> It also helps build a more generic driver and ease other OS integration
>> needed by customers (e.g. QNX, Win10).
>>
>> Lucas,
>> How do you think of it?
> 
> I don't yet buy the security argument. There are many more shared parts
> on the SoC, like the clock controller, that would need to be taken away
> from the non-secure world if one would want to run an untrusted OS
> kernel on a i.MX8M system.
> 
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so
> all shared critical peripherals are solely under firmware control.

It might be possible to rework this to use some form of SCMI-over-SMC 
instead of vendor-specific SMCCC SIP calls

+SCMI maintainer

> I agree that it might make sense to move some parts into the firmware
> and have much simpler OS level drivers, but I don't agree on the
> implementation direction taken here. Growing custom PSCI extension
> interfaces will only get us so far, without solving the system security
> issue in a holistic way. It is my strong believe that only a complete
> rearchitecture of the OS support on top of a ARM SCPI firmware
> interface can solve this properly.
Hiding everything critical for security (especially CCM) behind a SCMI 
interface would be a large amount of work but introducing SCMI 
incrementally (starting with imx8mm power) would be useful by itself 
because it simplifies OS implementation.

Many at NXP have attempted to evaluate SCMI and their conclusion has 
always been that "many extensions are required".

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

Am Mittwoch, den 17.04.2019, 12:40 +0000 schrieb Leonard Crestez:
> On 4/17/2019 3:13 PM, Lucas Stach wrote:
> > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> > > > From: Jacky Bai
> > > > Sent: Wednesday, April 17, 2019 1:27 PM
> > > > 
> > > > The i.MX8M family is a set of NXP product focus on delivering the latest and
> > > > greatest video and audio experience combining state-of-the-art media-specific
> > > > features with high-performance processing while optimized for lowest power
> > > > consumption.
> > > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
> > > > this family.
> > > > 
> > > > The GPC module is used to manage the PU power domains' power on/off. For
> > > > the whole i.MX8M family, different SoC has differnt power domain design. the
> > > > power up sequence has significant difference.
> > > > all the power sequence must be guaranteed by SW. Some domains' power up
> > > > sequence need to access the SRC module or sub-system specific GPR.
> > > > the SRC register & SS's register are not in in the GPC's memory range.
> > > > 
> > > > it makes us hard to use the GPCv2 driver to cover all the different power up
> > > > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
> > > > to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
> > > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
> > > > self-contained. Accessing the non-driver specific module's register is a bad
> > > > practice. Although, the GPC module provided the similar function for PU power
> > > > domain, but it is not 100% compatible with GPCv2.
> > > > 
> > > > The most important thing is that the GPC & SRC module is a security critical
> > > > resource that security permission must be considered when building the
> > > > security system. The GPC module is not only used by PU power domain power
> > > > on/off. It is also used by the TF-A PSCI code to do the CPU core power
> > > > management. the SRC module control the CPU CORE reset and the CPU reset
> > > > vector address. if we give the non-secure world write permission to SRC.
> > > > System can be easily induced to malicious code.
> > > 
> > > Considering the security issue, it looks to me a right direction to move GPC
> > > power handling into ATF.
> > > It also helps build a more generic driver and ease other OS integration
> > > needed by customers (e.g. QNX, Win10).
> > > 
> > > Lucas,
> > > How do you think of it?
> > 
> > I don't yet buy the security argument. There are many more shared parts
> > on the SoC, like the clock controller, that would need to be taken away
> > from the non-secure world if one would want to run an untrusted OS
> > kernel on a i.MX8M system.
> > 
> > To properly implement security on any i.MX8M based system the firmware
> > would need to grow something like a full ARM SCPI implementation, so
> > all shared critical peripherals are solely under firmware control.
> 
> It might be possible to rework this to use some form of SCMI-over-SMC 
> instead of vendor-specific SMCCC SIP calls
> 
> +SCMI maintainer
> 
> > I agree that it might make sense to move some parts into the firmware
> > and have much simpler OS level drivers, but I don't agree on the
> > implementation direction taken here. Growing custom PSCI extension
> > interfaces will only get us so far, without solving the system security
> > issue in a holistic way. It is my strong believe that only a complete
> > rearchitecture of the OS support on top of a ARM SCPI firmware
> > interface can solve this properly.
> 
> Hiding everything critical for security (especially CCM) behind a SCMI 
> interface would be a large amount of work but introducing SCMI 
> incrementally (starting with imx8mm power) would be useful by itself 
> because it simplifies OS implementation.

I'm totally on-board with baby steps if it gets us into the right
direction, so what you propose makes sense to me.

What I'm not okay with is tying the upstream kernel into an ad-hoc
firmware interface in the name of system security, if there is no
chance that proper security will ever be able to be achieved with the
ad-hoc interface. Having dependencies between the OS kernel and system
firmware is a burden on system integrators and I'm only willing to
accept that burden if it's clear that there is some real value to it.

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On 17/04/2019 13:54, Lucas Stach wrote:
> Am Mittwoch, den 17.04.2019, 12:40 +0000 schrieb Leonard Crestez:
>> On 4/17/2019 3:13 PM, Lucas Stach wrote:
>>> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
>>>>> From: Jacky Bai
>>>>> Sent: Wednesday, April 17, 2019 1:27 PM
>>>>>
>>>>> The i.MX8M family is a set of NXP product focus on delivering the latest and
>>>>> greatest video and audio experience combining state-of-the-art media-specific
>>>>> features with high-performance processing while optimized for lowest power
>>>>> consumption.
>>>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
>>>>> this family.
>>>>>
>>>>> The GPC module is used to manage the PU power domains' power on/off. For
>>>>> the whole i.MX8M family, different SoC has differnt power domain design. the
>>>>> power up sequence has significant difference.
>>>>> all the power sequence must be guaranteed by SW. Some domains' power up
>>>>> sequence need to access the SRC module or sub-system specific GPR.
>>>>> the SRC register & SS's register are not in in the GPC's memory range.
>>>>>
>>>>> it makes us hard to use the GPCv2 driver to cover all the different power up
>>>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
>>>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
>>>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
>>>>> self-contained. Accessing the non-driver specific module's register is a bad
>>>>> practice. Although, the GPC module provided the similar function for PU power
>>>>> domain, but it is not 100% compatible with GPCv2.
>>>>>
>>>>> The most important thing is that the GPC & SRC module is a security critical
>>>>> resource that security permission must be considered when building the
>>>>> security system. The GPC module is not only used by PU power domain power
>>>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power
>>>>> management. the SRC module control the CPU CORE reset and the CPU reset
>>>>> vector address. if we give the non-secure world write permission to SRC.
>>>>> System can be easily induced to malicious code.
>>>>
>>>> Considering the security issue, it looks to me a right direction to move GPC
>>>> power handling into ATF.
>>>> It also helps build a more generic driver and ease other OS integration
>>>> needed by customers (e.g. QNX, Win10).
>>>>
>>>> Lucas,
>>>> How do you think of it?
>>>
>>> I don't yet buy the security argument. There are many more shared parts
>>> on the SoC, like the clock controller, that would need to be taken away
>>> from the non-secure world if one would want to run an untrusted OS
>>> kernel on a i.MX8M system.
>>>
>>> To properly implement security on any i.MX8M based system the firmware
>>> would need to grow something like a full ARM SCPI implementation, so
>>> all shared critical peripherals are solely under firmware control.
>>
>> It might be possible to rework this to use some form of SCMI-over-SMC 
>> instead of vendor-specific SMCCC SIP calls
>>
>> +SCMI maintainer
>>
>>> I agree that it might make sense to move some parts into the firmware
>>> and have much simpler OS level drivers, but I don't agree on the
>>> implementation direction taken here. Growing custom PSCI extension
>>> interfaces will only get us so far, without solving the system security
>>> issue in a holistic way. It is my strong believe that only a complete
>>> rearchitecture of the OS support on top of a ARM SCPI firmware
>>> interface can solve this properly.
>>
>> Hiding everything critical for security (especially CCM) behind a SCMI 
>> interface would be a large amount of work but introducing SCMI 
>> incrementally (starting with imx8mm power) would be useful by itself 
>> because it simplifies OS implementation.
> 
> I'm totally on-board with baby steps if it gets us into the right
> direction, so what you propose makes sense to me.
> 
> What I'm not okay with is tying the upstream kernel into an ad-hoc
> firmware interface in the name of system security,

Exactly, sorry I should have read through the thread. I just responded
in other email with similar thoughts/concerns.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Peng Fan]

> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> On 4/17/2019 3:13 PM, Lucas Stach wrote:
> > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> >>> From: Jacky Bai
> >>> Sent: Wednesday, April 17, 2019 1:27 PM
> >>>
> >>> The i.MX8M family is a set of NXP product focus on delivering the
> >>> latest and greatest video and audio experience combining
> >>> state-of-the-art media-specific features with high-performance
> >>> processing while optimized for lowest power consumption.
> >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong
> >>> to this family.
> >>>
> >>> The GPC module is used to manage the PU power domains' power on/off.
> >>> For the whole i.MX8M family, different SoC has differnt power domain
> >>> design. the power up sequence has significant difference.
> >>> all the power sequence must be guaranteed by SW. Some domains'
> power
> >>> up sequence need to access the SRC module or sub-system specific GPR.
> >>> the SRC register & SS's register are not in in the GPC's memory range.
> >>>
> >>> it makes us hard to use the GPCv2 driver to cover all the different
> >>> power up requirement. Each time, a new SoC is added, we must modify
> >>> the GPCv2 driver to make it resuable for it. a lot of code need to be added
> in GPCv2 to support it.
> >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT
> >>> be self-contained. Accessing the non-driver specific module's
> >>> register is a bad practice. Although, the GPC module provided the
> >>> similar function for PU power domain, but it is not 100% compatible with
> GPCv2.
> >>>
> >>> The most important thing is that the GPC & SRC module is a security
> >>> critical resource that security permission must be considered when
> >>> building the security system. The GPC module is not only used by PU
> >>> power domain power on/off. It is also used by the TF-A PSCI code to
> >>> do the CPU core power management. the SRC module control the CPU
> >>> CORE reset and the CPU reset vector address. if we give the non-secure
> world write permission to SRC.
> >>> System can be easily induced to malicious code.
> >>
> >> Considering the security issue, it looks to me a right direction to
> >> move GPC power handling into ATF.
> >> It also helps build a more generic driver and ease other OS
> >> integration needed by customers (e.g. QNX, Win10).
> >>
> >> Lucas,
> >> How do you think of it?
> >
> > I don't yet buy the security argument. There are many more shared
> > parts on the SoC, like the clock controller, that would need to be
> > taken away from the non-secure world if one would want to run an
> > untrusted OS kernel on a i.MX8M system.
> >
> > To properly implement security on any i.MX8M based system the firmware
> > would need to grow something like a full ARM SCPI implementation, so
> > all shared critical peripherals are solely under firmware control.
> 
> It might be possible to rework this to use some form of SCMI-over-SMC
> instead of vendor-specific SMCCC SIP calls

Whether SCMI or just SIP, it will make it easy to support virtualization(partition)
or TEE.

> 
> +SCMI maintainer

We need implement firmware in ATF, and use SMC as the mailbox.
I have taken Andre's previous patch to support smc mailbox and addressed
some comments, and trying integrate with SCMI.
The major issue is SCMI spec does not include SMC support.

Sudeep, do you have any suggestions?

Thanks,
Peng.
> 
> > I agree that it might make sense to move some parts into the firmware
> > and have much simpler OS level drivers, but I don't agree on the
> > implementation direction taken here. Growing custom PSCI extension
> > interfaces will only get us so far, without solving the system
> > security issue in a holistic way. It is my strong believe that only a
> > complete rearchitecture of the OS support on top of a ARM SCPI
> > firmware interface can solve this properly.
> Hiding everything critical for security (especially CCM) behind a SCMI
> interface would be a large amount of work but introducing SCMI
> incrementally (starting with imx8mm power) would be useful by itself because
> it simplifies OS implementation.
> 
> Many at NXP have attempted to evaluate SCMI and their conclusion has
> always been that "many extensions are required".
> 
> --
> Regards,
> Leonard

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Peng Fan]

> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> On 4/17/2019 3:13 PM, Lucas Stach wrote:
> > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> >>> From: Jacky Bai
> >>> Sent: Wednesday, April 17, 2019 1:27 PM
> >>>
> >>> The i.MX8M family is a set of NXP product focus on delivering the
> >>> latest and greatest video and audio experience combining
> >>> state-of-the-art media-specific features with high-performance
> >>> processing while optimized for lowest power consumption.
> >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong
> >>> to this family.
> >>>
> >>> The GPC module is used to manage the PU power domains' power on/off.
> >>> For the whole i.MX8M family, different SoC has differnt power domain
> >>> design. the power up sequence has significant difference.
> >>> all the power sequence must be guaranteed by SW. Some domains'
> power
> >>> up sequence need to access the SRC module or sub-system specific GPR.
> >>> the SRC register & SS's register are not in in the GPC's memory range.
> >>>
> >>> it makes us hard to use the GPCv2 driver to cover all the different
> >>> power up requirement. Each time, a new SoC is added, we must modify
> >>> the GPCv2 driver to make it resuable for it. a lot of code need to be added
> in GPCv2 to support it.
> >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT
> >>> be self-contained. Accessing the non-driver specific module's
> >>> register is a bad practice. Although, the GPC module provided the
> >>> similar function for PU power domain, but it is not 100% compatible with
> GPCv2.
> >>>
> >>> The most important thing is that the GPC & SRC module is a security
> >>> critical resource that security permission must be considered when
> >>> building the security system. The GPC module is not only used by PU
> >>> power domain power on/off. It is also used by the TF-A PSCI code to
> >>> do the CPU core power management. the SRC module control the CPU
> >>> CORE reset and the CPU reset vector address. if we give the non-secure
> world write permission to SRC.
> >>> System can be easily induced to malicious code.
> >>
> >> Considering the security issue, it looks to me a right direction to
> >> move GPC power handling into ATF.
> >> It also helps build a more generic driver and ease other OS
> >> integration needed by customers (e.g. QNX, Win10).
> >>
> >> Lucas,
> >> How do you think of it?
> >
> > I don't yet buy the security argument. There are many more shared
> > parts on the SoC, like the clock controller, that would need to be
> > taken away from the non-secure world if one would want to run an
> > untrusted OS kernel on a i.MX8M system.
> >
> > To properly implement security on any i.MX8M based system the firmware
> > would need to grow something like a full ARM SCPI implementation, so
> > all shared critical peripherals are solely under firmware control.
> 
> It might be possible to rework this to use some form of SCMI-over-SMC
> instead of vendor-specific SMCCC SIP calls

Whether SCMI or just SIP, it will make it easy to support virtualization(partition)
or TEE.

> 
> +SCMI maintainer

We need implement firmware in ATF, and use SMC as the mailbox.
I have taken Andre's previous patch to support smc mailbox and addressed
some comments, and trying integrate with SCMI.
The major issue is SCMI spec does not include SMC support.

Sudeep, do you have any suggestions?

Thanks,
Peng.
> 
> > I agree that it might make sense to move some parts into the firmware
> > and have much simpler OS level drivers, but I don't agree on the
> > implementation direction taken here. Growing custom PSCI extension
> > interfaces will only get us so far, without solving the system
> > security issue in a holistic way. It is my strong believe that only a
> > complete rearchitecture of the OS support on top of a ARM SCPI
> > firmware interface can solve this properly.
> Hiding everything critical for security (especially CCM) behind a SCMI
> interface would be a large amount of work but introducing SCMI
> incrementally (starting with imx8mm power) would be useful by itself because
> it simplifies OS implementation.
> 
> Many at NXP have attempted to evaluate SCMI and their conclusion has
> always been that "many extensions are required".
> 
> --
> Regards,
> Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On 17/04/2019 13:40, Leonard Crestez wrote:
> On 4/17/2019 3:13 PM, Lucas Stach wrote:

[...]

>>
>> I don't yet buy the security argument. There are many more shared parts
>> on the SoC, like the clock controller, that would need to be taken away
>> from the non-secure world if one would want to run an untrusted OS
>> kernel on a i.MX8M system.
>>
>> To properly implement security on any i.MX8M based system the firmware
>> would need to grow something like a full ARM SCPI implementation, so
>> all shared critical peripherals are solely under firmware control.
> 
> It might be possible to rework this to use some form of SCMI-over-SMC 
> instead of vendor-specific SMCCC SIP calls
> 

Sounds feasible and good if all the custom IDs/calls/..etc are well
hidden in the firmware(TF-A in this case) behind the existing
abstraction in Linux kernel.

> +SCMI maintainer
> 

Thanks for including.

>> I agree that it might make sense to move some parts into the firmware
>> and have much simpler OS level drivers, but I don't agree on the
>> implementation direction taken here. Growing custom PSCI extension
>> interfaces will only get us so far, without solving the system security
>> issue in a holistic way. It is my strong believe that only a complete
>> rearchitecture of the OS support on top of a ARM SCPI firmware
>> interface can solve this properly.

+1 again, just to re-iterate the emphasis on the above and the degree to
which I align with it.

> Hiding everything critical for security (especially CCM) behind a SCMI 
> interface would be a large amount of work but introducing SCMI 
> incrementally (starting with imx8mm power) would be useful by itself 
> because it simplifies OS implementation.
> 

Agreed, but not at the expense of introducing and maintaining *random*
*one-off* *custom* SMC extensions. Sorry, that's not open to debate.

> Many at NXP have attempted to evaluate SCMI and their conclusion has 
> always been that "many extensions are required".
> 

I would like to hear the evaluation. Don't assume that you need to
implement something similar to ARM SCMI reference design. All OSPM like
Linux kernel cares is conformance to the interface, what/how you
implement on the other side is left to you.

-- 
Regards,
Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On 17/04/2019 13:40, Leonard Crestez wrote:
> On 4/17/2019 3:13 PM, Lucas Stach wrote:

[...]

>>
>> I don't yet buy the security argument. There are many more shared parts
>> on the SoC, like the clock controller, that would need to be taken away
>> from the non-secure world if one would want to run an untrusted OS
>> kernel on a i.MX8M system.
>>
>> To properly implement security on any i.MX8M based system the firmware
>> would need to grow something like a full ARM SCPI implementation, so
>> all shared critical peripherals are solely under firmware control.
> 
> It might be possible to rework this to use some form of SCMI-over-SMC 
> instead of vendor-specific SMCCC SIP calls
> 

Sounds feasible and good if all the custom IDs/calls/..etc are well
hidden in the firmware(TF-A in this case) behind the existing
abstraction in Linux kernel.

> +SCMI maintainer
> 

Thanks for including.

>> I agree that it might make sense to move some parts into the firmware
>> and have much simpler OS level drivers, but I don't agree on the
>> implementation direction taken here. Growing custom PSCI extension
>> interfaces will only get us so far, without solving the system security
>> issue in a holistic way. It is my strong believe that only a complete
>> rearchitecture of the OS support on top of a ARM SCPI firmware
>> interface can solve this properly.

+1 again, just to re-iterate the emphasis on the above and the degree to
which I align with it.

> Hiding everything critical for security (especially CCM) behind a SCMI 
> interface would be a large amount of work but introducing SCMI 
> incrementally (starting with imx8mm power) would be useful by itself 
> because it simplifies OS implementation.
> 

Agreed, but not at the expense of introducing and maintaining *random*
*one-off* *custom* SMC extensions. Sorry, that's not open to debate.

> Many at NXP have attempted to evaluate SCMI and their conclusion has 
> always been that "many extensions are required".
> 

I would like to hear the evaluation. Don't assume that you need to
implement something similar to ARM SCMI reference design. All OSPM like
Linux kernel cares is conformance to the interface, what/how you
implement on the other side is left to you.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>> I don't yet buy the security argument. There are many more shared parts
>>> on the SoC, like the clock controller, that would need to be taken away
>>> from the non-secure world if one would want to run an untrusted OS
>>> kernel on a i.MX8M system.
>>>
>>> To properly implement security on any i.MX8M based system the firmware
>>> would need to grow something like a full ARM SCPI implementation, so
>>> all shared critical peripherals are solely under firmware control.
>>
>> It might be possible to rework this to use some form of SCMI-over-SMC
>> instead of vendor-specific SMCCC SIP calls
> 
> Sounds feasible and good if all the custom IDs/calls/..etc are well
> hidden in the firmware(TF-A in this case) behind the existing
> abstraction in Linux kernel.

>> Hiding everything critical for security (especially CCM) behind a SCMI
>> interface would be a large amount of work but introducing SCMI
>> incrementally (starting with imx8mm power) would be useful by itself
>> because it simplifies OS implementation.
> 
> Agreed, but not at the expense of introducing and maintaining *random*
> *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> 
>> Many at NXP have attempted to evaluate SCMI and their conclusion has
>> always been that "many extensions are required".
> 
> I would like to hear the evaluation. Don't assume that you need to
> implement something similar to ARM SCMI reference design. All OSPM like
> Linux kernel cares is conformance to the interface, what/how you
> implement on the other side is left to you.

Brief summary from some attempts at nudging NXP devs towards SCMI:


There is no SCMI-over-SMC support specified? This would make it possible 
to use SCMI as a purely software solution on platforms which did not 
take SCMI into account at hardware design time or which don't have a 
dedicated SCP inside the SOC. This applies to all imx.

Peng has been looking at some out-of-tree arm-smc-mailbox patches so 
it's not just NXP which would like the option of implementing SCMI 
vendor side in ATF. Like this: https://lwn.net/Articles/726861/

Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI 
message in EL2; checking if the guest is allowed to use that resource 
and then either forward to EL3 or return an error.


SCMI clock protocol does not cover muxes? On imx the clk hierarchy is 
very intricate and it relies on many clk core features (including 
notifiers) and occasional assigned-clocks-parents properties to control 
muxes from linux. Moving all that to firmware would be a huge amount of 
effort.

If SCMI included a generic clk mux and allowed keeping the clk hierarchy 
inside linux then the effort required for hiding the CCM would still be 
large, but more approachable. It would not "simplify the rich OS" but it 
would still improve security.


Last point is that SCMI does not cover pinctrl? This is a large chunk of 
firmware functionality on some imx and security control over individual 
pins is desirable.

--
Regards,
Leonard

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>> I don't yet buy the security argument. There are many more shared parts
>>> on the SoC, like the clock controller, that would need to be taken away
>>> from the non-secure world if one would want to run an untrusted OS
>>> kernel on a i.MX8M system.
>>>
>>> To properly implement security on any i.MX8M based system the firmware
>>> would need to grow something like a full ARM SCPI implementation, so
>>> all shared critical peripherals are solely under firmware control.
>>
>> It might be possible to rework this to use some form of SCMI-over-SMC
>> instead of vendor-specific SMCCC SIP calls
> 
> Sounds feasible and good if all the custom IDs/calls/..etc are well
> hidden in the firmware(TF-A in this case) behind the existing
> abstraction in Linux kernel.

>> Hiding everything critical for security (especially CCM) behind a SCMI
>> interface would be a large amount of work but introducing SCMI
>> incrementally (starting with imx8mm power) would be useful by itself
>> because it simplifies OS implementation.
> 
> Agreed, but not at the expense of introducing and maintaining *random*
> *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> 
>> Many at NXP have attempted to evaluate SCMI and their conclusion has
>> always been that "many extensions are required".
> 
> I would like to hear the evaluation. Don't assume that you need to
> implement something similar to ARM SCMI reference design. All OSPM like
> Linux kernel cares is conformance to the interface, what/how you
> implement on the other side is left to you.

Brief summary from some attempts at nudging NXP devs towards SCMI:


There is no SCMI-over-SMC support specified? This would make it possible 
to use SCMI as a purely software solution on platforms which did not 
take SCMI into account at hardware design time or which don't have a 
dedicated SCP inside the SOC. This applies to all imx.

Peng has been looking at some out-of-tree arm-smc-mailbox patches so 
it's not just NXP which would like the option of implementing SCMI 
vendor side in ATF. Like this: https://lwn.net/Articles/726861/

Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI 
message in EL2; checking if the guest is allowed to use that resource 
and then either forward to EL3 or return an error.


SCMI clock protocol does not cover muxes? On imx the clk hierarchy is 
very intricate and it relies on many clk core features (including 
notifiers) and occasional assigned-clocks-parents properties to control 
muxes from linux. Moving all that to firmware would be a huge amount of 
effort.

If SCMI included a generic clk mux and allowed keeping the clk hierarchy 
inside linux then the effort required for hiding the CCM would still be 
large, but more approachable. It would not "simplify the rich OS" but it 
would still improve security.


Last point is that SCMI does not cover pinctrl? This is a large chunk of 
firmware functionality on some imx and security control over individual 
pins is desirable.

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> >>> I don't yet buy the security argument. There are many more shared parts
> >>> on the SoC, like the clock controller, that would need to be taken away
> >>> from the non-secure world if one would want to run an untrusted OS
> >>> kernel on a i.MX8M system.
> >>>
> >>> To properly implement security on any i.MX8M based system the firmware
> >>> would need to grow something like a full ARM SCPI implementation, so
> >>> all shared critical peripherals are solely under firmware control.
> >>
> >> It might be possible to rework this to use some form of SCMI-over-SMC
> >> instead of vendor-specific SMCCC SIP calls
> >
> > Sounds feasible and good if all the custom IDs/calls/..etc are well
> > hidden in the firmware(TF-A in this case) behind the existing
> > abstraction in Linux kernel.
>
> >> Hiding everything critical for security (especially CCM) behind a SCMI
> >> interface would be a large amount of work but introducing SCMI
> >> incrementally (starting with imx8mm power) would be useful by itself
> >> because it simplifies OS implementation.
> >
> > Agreed, but not at the expense of introducing and maintaining *random*
> > *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> >
> >> Many at NXP have attempted to evaluate SCMI and their conclusion has
> >> always been that "many extensions are required".
> >
> > I would like to hear the evaluation. Don't assume that you need to
> > implement something similar to ARM SCMI reference design. All OSPM like
> > Linux kernel cares is conformance to the interface, what/how you
> > implement on the other side is left to you.
>
> Brief summary from some attempts at nudging NXP devs towards SCMI:
>

Thanks for providing the evaluation details.

>
> There is no SCMI-over-SMC support specified? This would make it possible
> to use SCMI as a purely software solution on platforms which did not
> take SCMI into account at hardware design time or which don't have a
> dedicated SCP inside the SOC. This applies to all imx.
>

While I admit, the section of SCMI specification that touches transport
is quite lean, I would view it as done intentionally as the specification
is mainly concentrated on it's subject matter which is protocol and not
the transport itself. So did the evaluation attempted to consider/try
SMC as transport retaining protocol as is ?

I can't see any issues with that and hence I am asking it loud here.

> Peng has been looking at some out-of-tree arm-smc-mailbox patches so
> it's not just NXP which would like the option of implementing SCMI
> vendor side in ATF. Like this: https://lwn.net/Articles/726861/
>

OK, any inputs from that study ?

> Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI
> message in EL2; checking if the guest is allowed to use that resource
> and then either forward to EL3 or return an error.
>

Why are you mixing virtualisation and EL2 here ? Yes we need them but
it should be optional and if a platform doesn't need it, it should be
possible to skip it.

>
> SCMI clock protocol does not cover muxes? On imx the clk hierarchy is
> very intricate and it relies on many clk core features (including
> notifiers) and occasional assigned-clocks-parents properties to control
> muxes from linux. Moving all that to firmware would be a huge amount of
> effort.
>

Yes it may be huge amount of work. But is it completely safe as claimed ?
Giving access to mux controls in OSPM is no so safe/secure in the modern
world. So you either make it safe with that extra huge effort needed or
just keep everything in OSPM. But IMO anything in between is not worth it.

> If SCMI included a generic clk mux and allowed keeping the clk hierarchy
> inside linux then the effort required for hiding the CCM would still be
> large, but more approachable. It would not "simplify the rich OS" but it
> would still improve security.
>

Why do you need to keep the clk hierarchy in Linux ?

>
> Last point is that SCMI does not cover pinctrl? This is a large chunk of
> firmware functionality on some imx and security control over individual
> pins is desirable.
>

Yes but is that something available at runtime ? Can't that be one-off
firmware setting. Will Linux need to configure it differently on each boot ?
Just trying to understand. You say security control here and is it really
safe to give OS access to control those ?

In short, if you had a full blown protocol like few other platforms, the
push back would have been minimal. Instead, i.MX chose to implement a
solution which doesn't have a design thought before and custom SMC APIs
added on fly whenever a new request is raised by OSPM to control things
that it thinks it should. I am sure, the very next platform will have it's
own set of requirements and custom SMC APIs/interface and no one has even
bothered about long term maintenance of these.

So assuming that trend, I would NACK this as it stands.

--
Regards,
Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> >>> I don't yet buy the security argument. There are many more shared parts
> >>> on the SoC, like the clock controller, that would need to be taken away
> >>> from the non-secure world if one would want to run an untrusted OS
> >>> kernel on a i.MX8M system.
> >>>
> >>> To properly implement security on any i.MX8M based system the firmware
> >>> would need to grow something like a full ARM SCPI implementation, so
> >>> all shared critical peripherals are solely under firmware control.
> >>
> >> It might be possible to rework this to use some form of SCMI-over-SMC
> >> instead of vendor-specific SMCCC SIP calls
> >
> > Sounds feasible and good if all the custom IDs/calls/..etc are well
> > hidden in the firmware(TF-A in this case) behind the existing
> > abstraction in Linux kernel.
>
> >> Hiding everything critical for security (especially CCM) behind a SCMI
> >> interface would be a large amount of work but introducing SCMI
> >> incrementally (starting with imx8mm power) would be useful by itself
> >> because it simplifies OS implementation.
> >
> > Agreed, but not at the expense of introducing and maintaining *random*
> > *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> >
> >> Many at NXP have attempted to evaluate SCMI and their conclusion has
> >> always been that "many extensions are required".
> >
> > I would like to hear the evaluation. Don't assume that you need to
> > implement something similar to ARM SCMI reference design. All OSPM like
> > Linux kernel cares is conformance to the interface, what/how you
> > implement on the other side is left to you.
>
> Brief summary from some attempts at nudging NXP devs towards SCMI:
>

Thanks for providing the evaluation details.

>
> There is no SCMI-over-SMC support specified? This would make it possible
> to use SCMI as a purely software solution on platforms which did not
> take SCMI into account at hardware design time or which don't have a
> dedicated SCP inside the SOC. This applies to all imx.
>

While I admit, the section of SCMI specification that touches transport
is quite lean, I would view it as done intentionally as the specification
is mainly concentrated on it's subject matter which is protocol and not
the transport itself. So did the evaluation attempted to consider/try
SMC as transport retaining protocol as is ?

I can't see any issues with that and hence I am asking it loud here.

> Peng has been looking at some out-of-tree arm-smc-mailbox patches so
> it's not just NXP which would like the option of implementing SCMI
> vendor side in ATF. Like this: https://lwn.net/Articles/726861/
>

OK, any inputs from that study ?

> Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI
> message in EL2; checking if the guest is allowed to use that resource
> and then either forward to EL3 or return an error.
>

Why are you mixing virtualisation and EL2 here ? Yes we need them but
it should be optional and if a platform doesn't need it, it should be
possible to skip it.

>
> SCMI clock protocol does not cover muxes? On imx the clk hierarchy is
> very intricate and it relies on many clk core features (including
> notifiers) and occasional assigned-clocks-parents properties to control
> muxes from linux. Moving all that to firmware would be a huge amount of
> effort.
>

Yes it may be huge amount of work. But is it completely safe as claimed ?
Giving access to mux controls in OSPM is no so safe/secure in the modern
world. So you either make it safe with that extra huge effort needed or
just keep everything in OSPM. But IMO anything in between is not worth it.

> If SCMI included a generic clk mux and allowed keeping the clk hierarchy
> inside linux then the effort required for hiding the CCM would still be
> large, but more approachable. It would not "simplify the rich OS" but it
> would still improve security.
>

Why do you need to keep the clk hierarchy in Linux ?

>
> Last point is that SCMI does not cover pinctrl? This is a large chunk of
> firmware functionality on some imx and security control over individual
> pins is desirable.
>

Yes but is that something available at runtime ? Can't that be one-off
firmware setting. Will Linux need to configure it differently on each boot ?
Just trying to understand. You say security control here and is it really
safe to give OS access to control those ?

In short, if you had a full blown protocol like few other platforms, the
push back would have been minimal. Instead, i.MX chose to implement a
solution which doesn't have a design thought before and custom SMC APIs
added on fly whenever a new request is raised by OSPM to control things
that it thinks it should. I am sure, the very next platform will have it's
own set of requirements and custom SMC APIs/interface and no one has even
bothered about long term maintenance of these.

So assuming that trend, I would NACK this as it stands.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Adam Ford]

On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > >>> I don't yet buy the security argument. There are many more shared parts
> > >>> on the SoC, like the clock controller, that would need to be taken away
> > >>> from the non-secure world if one would want to run an untrusted OS
> > >>> kernel on a i.MX8M system.
> > >>>
> > >>> To properly implement security on any i.MX8M based system the firmware
> > >>> would need to grow something like a full ARM SCPI implementation, so
> > >>> all shared critical peripherals are solely under firmware control.
> > >>
> > >> It might be possible to rework this to use some form of SCMI-over-SMC
> > >> instead of vendor-specific SMCCC SIP calls

I was just curious to know if there is any progress being made on
this.  The i.mx8mm-evk is missing functionality upstream and I think
the power domain support would help enable some of these features.

thanks

adam
> > >
> > > Sounds feasible and good if all the custom IDs/calls/..etc are well
> > > hidden in the firmware(TF-A in this case) behind the existing
> > > abstraction in Linux kernel.
> >
> > >> Hiding everything critical for security (especially CCM) behind a SCMI
> > >> interface would be a large amount of work but introducing SCMI
> > >> incrementally (starting with imx8mm power) would be useful by itself
> > >> because it simplifies OS implementation.
> > >
> > > Agreed, but not at the expense of introducing and maintaining *random*
> > > *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> > >
> > >> Many at NXP have attempted to evaluate SCMI and their conclusion has
> > >> always been that "many extensions are required".
> > >
> > > I would like to hear the evaluation. Don't assume that you need to
> > > implement something similar to ARM SCMI reference design. All OSPM like
> > > Linux kernel cares is conformance to the interface, what/how you
> > > implement on the other side is left to you.
> >
> > Brief summary from some attempts at nudging NXP devs towards SCMI:
> >
>
> Thanks for providing the evaluation details.
>
> >
> > There is no SCMI-over-SMC support specified? This would make it possible
> > to use SCMI as a purely software solution on platforms which did not
> > take SCMI into account at hardware design time or which don't have a
> > dedicated SCP inside the SOC. This applies to all imx.
> >
>
> While I admit, the section of SCMI specification that touches transport
> is quite lean, I would view it as done intentionally as the specification
> is mainly concentrated on it's subject matter which is protocol and not
> the transport itself. So did the evaluation attempted to consider/try
> SMC as transport retaining protocol as is ?
>
> I can't see any issues with that and hence I am asking it loud here.
>
> > Peng has been looking at some out-of-tree arm-smc-mailbox patches so
> > it's not just NXP which would like the option of implementing SCMI
> > vendor side in ATF. Like this: https://lwn.net/Articles/726861/
> >
>
> OK, any inputs from that study ?
>
> > Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI
> > message in EL2; checking if the guest is allowed to use that resource
> > and then either forward to EL3 or return an error.
> >
>
> Why are you mixing virtualisation and EL2 here ? Yes we need them but
> it should be optional and if a platform doesn't need it, it should be
> possible to skip it.
>
> >
> > SCMI clock protocol does not cover muxes? On imx the clk hierarchy is
> > very intricate and it relies on many clk core features (including
> > notifiers) and occasional assigned-clocks-parents properties to control
> > muxes from linux. Moving all that to firmware would be a huge amount of
> > effort.
> >
>
> Yes it may be huge amount of work. But is it completely safe as claimed ?
> Giving access to mux controls in OSPM is no so safe/secure in the modern
> world. So you either make it safe with that extra huge effort needed or
> just keep everything in OSPM. But IMO anything in between is not worth it.
>
> > If SCMI included a generic clk mux and allowed keeping the clk hierarchy
> > inside linux then the effort required for hiding the CCM would still be
> > large, but more approachable. It would not "simplify the rich OS" but it
> > would still improve security.
> >
>
> Why do you need to keep the clk hierarchy in Linux ?
>
> >
> > Last point is that SCMI does not cover pinctrl? This is a large chunk of
> > firmware functionality on some imx and security control over individual
> > pins is desirable.
> >
>
> Yes but is that something available at runtime ? Can't that be one-off
> firmware setting. Will Linux need to configure it differently on each boot ?
> Just trying to understand. You say security control here and is it really
> safe to give OS access to control those ?
>
> In short, if you had a full blown protocol like few other platforms, the
> push back would have been minimal. Instead, i.MX chose to implement a
> solution which doesn't have a design thought before and custom SMC APIs
> added on fly whenever a new request is raised by OSPM to control things
> that it thinks it should. I am sure, the very next platform will have it's
> own set of requirements and custom SMC APIs/interface and no one has even
> bothered about long term maintenance of these.
>
> So assuming that trend, I would NACK this as it stands.
>
> --
> Regards,
> Sudeep
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Adam Ford]

On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > >>> I don't yet buy the security argument. There are many more shared parts
> > >>> on the SoC, like the clock controller, that would need to be taken away
> > >>> from the non-secure world if one would want to run an untrusted OS
> > >>> kernel on a i.MX8M system.
> > >>>
> > >>> To properly implement security on any i.MX8M based system the firmware
> > >>> would need to grow something like a full ARM SCPI implementation, so
> > >>> all shared critical peripherals are solely under firmware control.
> > >>
> > >> It might be possible to rework this to use some form of SCMI-over-SMC
> > >> instead of vendor-specific SMCCC SIP calls

I was just curious to know if there is any progress being made on
this.  The i.mx8mm-evk is missing functionality upstream and I think
the power domain support would help enable some of these features.

thanks

adam
> > >
> > > Sounds feasible and good if all the custom IDs/calls/..etc are well
> > > hidden in the firmware(TF-A in this case) behind the existing
> > > abstraction in Linux kernel.
> >
> > >> Hiding everything critical for security (especially CCM) behind a SCMI
> > >> interface would be a large amount of work but introducing SCMI
> > >> incrementally (starting with imx8mm power) would be useful by itself
> > >> because it simplifies OS implementation.
> > >
> > > Agreed, but not at the expense of introducing and maintaining *random*
> > > *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> > >
> > >> Many at NXP have attempted to evaluate SCMI and their conclusion has
> > >> always been that "many extensions are required".
> > >
> > > I would like to hear the evaluation. Don't assume that you need to
> > > implement something similar to ARM SCMI reference design. All OSPM like
> > > Linux kernel cares is conformance to the interface, what/how you
> > > implement on the other side is left to you.
> >
> > Brief summary from some attempts at nudging NXP devs towards SCMI:
> >
>
> Thanks for providing the evaluation details.
>
> >
> > There is no SCMI-over-SMC support specified? This would make it possible
> > to use SCMI as a purely software solution on platforms which did not
> > take SCMI into account at hardware design time or which don't have a
> > dedicated SCP inside the SOC. This applies to all imx.
> >
>
> While I admit, the section of SCMI specification that touches transport
> is quite lean, I would view it as done intentionally as the specification
> is mainly concentrated on it's subject matter which is protocol and not
> the transport itself. So did the evaluation attempted to consider/try
> SMC as transport retaining protocol as is ?
>
> I can't see any issues with that and hence I am asking it loud here.
>
> > Peng has been looking at some out-of-tree arm-smc-mailbox patches so
> > it's not just NXP which would like the option of implementing SCMI
> > vendor side in ATF. Like this: https://lwn.net/Articles/726861/
> >
>
> OK, any inputs from that study ?
>
> > Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI
> > message in EL2; checking if the guest is allowed to use that resource
> > and then either forward to EL3 or return an error.
> >
>
> Why are you mixing virtualisation and EL2 here ? Yes we need them but
> it should be optional and if a platform doesn't need it, it should be
> possible to skip it.
>
> >
> > SCMI clock protocol does not cover muxes? On imx the clk hierarchy is
> > very intricate and it relies on many clk core features (including
> > notifiers) and occasional assigned-clocks-parents properties to control
> > muxes from linux. Moving all that to firmware would be a huge amount of
> > effort.
> >
>
> Yes it may be huge amount of work. But is it completely safe as claimed ?
> Giving access to mux controls in OSPM is no so safe/secure in the modern
> world. So you either make it safe with that extra huge effort needed or
> just keep everything in OSPM. But IMO anything in between is not worth it.
>
> > If SCMI included a generic clk mux and allowed keeping the clk hierarchy
> > inside linux then the effort required for hiding the CCM would still be
> > large, but more approachable. It would not "simplify the rich OS" but it
> > would still improve security.
> >
>
> Why do you need to keep the clk hierarchy in Linux ?
>
> >
> > Last point is that SCMI does not cover pinctrl? This is a large chunk of
> > firmware functionality on some imx and security control over individual
> > pins is desirable.
> >
>
> Yes but is that something available at runtime ? Can't that be one-off
> firmware setting. Will Linux need to configure it differently on each boot ?
> Just trying to understand. You say security control here and is it really
> safe to give OS access to control those ?
>
> In short, if you had a full blown protocol like few other platforms, the
> push back would have been minimal. Instead, i.MX chose to implement a
> solution which doesn't have a design thought before and custom SMC APIs
> added on fly whenever a new request is raised by OSPM to control things
> that it thinks it should. I am sure, the very next platform will have it's
> own set of requirements and custom SMC APIs/interface and no one has even
> bothered about long term maintenance of these.
>
> So assuming that trend, I would NACK this as it stands.
>
> --
> Regards,
> Sudeep
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

Hi,

On 07.11.19 22:28, Adam Ford wrote:
> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>> I don't yet buy the security argument. There are many more shared parts
>>>>>> on the SoC, like the clock controller, that would need to be taken away
>>>>>> from the non-secure world if one would want to run an untrusted OS
>>>>>> kernel on a i.MX8M system.
>>>>>>
>>>>>> To properly implement security on any i.MX8M based system the firmware
>>>>>> would need to grow something like a full ARM SCPI implementation, so
>>>>>> all shared critical peripherals are solely under firmware control.
>>>>>
>>>>> It might be possible to rework this to use some form of SCMI-over-SMC
>>>>> instead of vendor-specific SMCCC SIP calls
> 
> I was just curious to know if there is any progress being made on
> this.  The i.mx8mm-evk is missing functionality upstream and I think
> the power domain support would help enable some of these features.
> 

Has there been any decision or action taken in this topic?
Will the power domain driver as proposed in this patch be upstreamed at 
some time, or rather not?

I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) 
and I integrated display and graphics support from the downstream NXP 
kernel.

While most things already work fine, there's the issue of how to handle 
the power domains. Currently I need to ungate some clocks in the TF-A 
BL31 to get for example the GPU running. If I understand this correctly 
the proposed power domain driver could handle this in Linux otherwise.

Thanks,
Frieder

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

Hi,

On 07.11.19 22:28, Adam Ford wrote:
> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>> I don't yet buy the security argument. There are many more shared parts
>>>>>> on the SoC, like the clock controller, that would need to be taken away
>>>>>> from the non-secure world if one would want to run an untrusted OS
>>>>>> kernel on a i.MX8M system.
>>>>>>
>>>>>> To properly implement security on any i.MX8M based system the firmware
>>>>>> would need to grow something like a full ARM SCPI implementation, so
>>>>>> all shared critical peripherals are solely under firmware control.
>>>>>
>>>>> It might be possible to rework this to use some form of SCMI-over-SMC
>>>>> instead of vendor-specific SMCCC SIP calls
> 
> I was just curious to know if there is any progress being made on
> this.  The i.mx8mm-evk is missing functionality upstream and I think
> the power domain support would help enable some of these features.
> 

Has there been any decision or action taken in this topic?
Will the power domain driver as proposed in this patch be upstreamed at 
some time, or rather not?

I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) 
and I integrated display and graphics support from the downstream NXP 
kernel.

While most things already work fine, there's the issue of how to handle 
the power domains. Currently I need to ungate some clocks in the TF-A 
BL31 to get for example the GPU running. If I understand this correctly 
the proposed power domain driver could handle this in Linux otherwise.

Thanks,
Frieder
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

> -----Original Message-----
> From: Schrempf Frieder <frieder.schrempf@kontron.de>
> Sent: Thursday, February 13, 2020 5:16 PM
> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> <sudeep.holla@arm.com>
> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> Fan <peng.fan@nxp.com>; Souvik Chakravarty
> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> Hi,
> 
> On 07.11.19 22:28, Adam Ford wrote:
> > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> wrote:
> >>
> >> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> >>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> >>>>>> I don't yet buy the security argument. There are many more shared
> >>>>>> parts on the SoC, like the clock controller, that would need to
> >>>>>> be taken away from the non-secure world if one would want to run
> >>>>>> an untrusted OS kernel on a i.MX8M system.
> >>>>>>
> >>>>>> To properly implement security on any i.MX8M based system the
> >>>>>> firmware would need to grow something like a full ARM SCPI
> >>>>>> implementation, so all shared critical peripherals are solely under
> firmware control.
> >>>>>
> >>>>> It might be possible to rework this to use some form of
> >>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> >
> > I was just curious to know if there is any progress being made on
> > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > the power domain support would help enable some of these features.
> >
> 
> Has there been any decision or action taken in this topic?
> Will the power domain driver as proposed in this patch be upstreamed at
> some time, or rather not?
> 
> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> and I integrated display and graphics support from the downstream NXP
> kernel.
> 
> While most things already work fine, there's the issue of how to handle the
> power domains. Currently I need to ungate some clocks in the TF-A
> BL31 to get for example the GPU running. If I understand this correctly the
> proposed power domain driver could handle this in Linux otherwise.
> 

the SCMI over SMC is still under review

BR
Jacky Bai 
> Thanks,
> Frieder

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

> -----Original Message-----
> From: Schrempf Frieder <frieder.schrempf@kontron.de>
> Sent: Thursday, February 13, 2020 5:16 PM
> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> <sudeep.holla@arm.com>
> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> Fan <peng.fan@nxp.com>; Souvik Chakravarty
> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> Hi,
> 
> On 07.11.19 22:28, Adam Ford wrote:
> > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> wrote:
> >>
> >> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> >>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> >>>>>> I don't yet buy the security argument. There are many more shared
> >>>>>> parts on the SoC, like the clock controller, that would need to
> >>>>>> be taken away from the non-secure world if one would want to run
> >>>>>> an untrusted OS kernel on a i.MX8M system.
> >>>>>>
> >>>>>> To properly implement security on any i.MX8M based system the
> >>>>>> firmware would need to grow something like a full ARM SCPI
> >>>>>> implementation, so all shared critical peripherals are solely under
> firmware control.
> >>>>>
> >>>>> It might be possible to rework this to use some form of
> >>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> >
> > I was just curious to know if there is any progress being made on
> > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > the power domain support would help enable some of these features.
> >
> 
> Has there been any decision or action taken in this topic?
> Will the power domain driver as proposed in this patch be upstreamed at
> some time, or rather not?
> 
> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> and I integrated display and graphics support from the downstream NXP
> kernel.
> 
> While most things already work fine, there's the issue of how to handle the
> power domains. Currently I need to ungate some clocks in the TF-A
> BL31 to get for example the GPU running. If I understand this correctly the
> proposed power domain driver could handle this in Linux otherwise.
> 

the SCMI over SMC is still under review

BR
Jacky Bai 
> Thanks,
> Frieder
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

On 13.02.20 10:21, Jacky Bai wrote:
>> -----Original Message-----
>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>> Sent: Thursday, February 13, 2020 5:16 PM
>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>> <sudeep.holla@arm.com>
>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>
>> Hi,
>>
>> On 07.11.19 22:28, Adam Ford wrote:
>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>>
>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>
>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>> implementation, so all shared critical peripherals are solely under
>> firmware control.
>>>>>>>
>>>>>>> It might be possible to rework this to use some form of
>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>
>>> I was just curious to know if there is any progress being made on
>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>> the power domain support would help enable some of these features.
>>>
>>
>> Has there been any decision or action taken in this topic?
>> Will the power domain driver as proposed in this patch be upstreamed at
>> some time, or rather not?
>>
>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>> and I integrated display and graphics support from the downstream NXP
>> kernel.
>>
>> While most things already work fine, there's the issue of how to handle the
>> power domains. Currently I need to ungate some clocks in the TF-A
>> BL31 to get for example the GPU running. If I understand this correctly the
>> proposed power domain driver could handle this in Linux otherwise.
>>
> 
> the SCMI over SMC is still under review
> 

Ok, I see. Thanks for the information.
Once the SCMI over SMC driver is available in Linux, what else needs to 
be done to handle the example case given above (GPU root clock ungate)?

I guess this would need an imx-specific handler in the TF-A. Is this 
interface already available in mainline TF-A?

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

On 13.02.20 10:21, Jacky Bai wrote:
>> -----Original Message-----
>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>> Sent: Thursday, February 13, 2020 5:16 PM
>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>> <sudeep.holla@arm.com>
>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>
>> Hi,
>>
>> On 07.11.19 22:28, Adam Ford wrote:
>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>>
>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>
>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>> implementation, so all shared critical peripherals are solely under
>> firmware control.
>>>>>>>
>>>>>>> It might be possible to rework this to use some form of
>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>
>>> I was just curious to know if there is any progress being made on
>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>> the power domain support would help enable some of these features.
>>>
>>
>> Has there been any decision or action taken in this topic?
>> Will the power domain driver as proposed in this patch be upstreamed at
>> some time, or rather not?
>>
>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>> and I integrated display and graphics support from the downstream NXP
>> kernel.
>>
>> While most things already work fine, there's the issue of how to handle the
>> power domains. Currently I need to ungate some clocks in the TF-A
>> BL31 to get for example the GPU running. If I understand this correctly the
>> proposed power domain driver could handle this in Linux otherwise.
>>
> 
> the SCMI over SMC is still under review
> 

Ok, I see. Thanks for the information.
Once the SCMI over SMC driver is available in Linux, what else needs to 
be done to handle the example case given above (GPU root clock ungate)?

I guess this would need an imx-specific handler in the TF-A. Is this 
interface already available in mainline TF-A?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > -----Original Message-----
> > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > Sent: Thursday, February 13, 2020 5:16 PM
> > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > <sudeep.holla@arm.com>
> > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > 
> > Hi,
> > 
> > On 07.11.19 22:28, Adam Ford wrote:
> > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > wrote:
> > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > 
> > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > implementation, so all shared critical peripherals are solely under
> > firmware control.
> > > > > > > It might be possible to rework this to use some form of
> > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > 
> > > I was just curious to know if there is any progress being made on
> > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > the power domain support would help enable some of these features.
> > > 
> > 
> > Has there been any decision or action taken in this topic?
> > Will the power domain driver as proposed in this patch be upstreamed at
> > some time, or rather not?
> > 
> > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > and I integrated display and graphics support from the downstream NXP
> > kernel.
> > 
> > While most things already work fine, there's the issue of how to handle the
> > power domains. Currently I need to ungate some clocks in the TF-A
> > BL31 to get for example the GPU running. If I understand this correctly the
> > proposed power domain driver could handle this in Linux otherwise.
> > 
> 
> the SCMI over SMC is still under review

Even if the SCMI over SMC is ready at some point, it's still unclear to
me how you intend to abstract the GPC behind the SCMI interface in the
TF-A. The power domains have dependencies both into the regulator and
the clock framework. Both are currently under exclusive control of the
rich OS. How do you intend to allow the TF-A to control the power
supplies and necessary reset clocks without messing up any state in the
rich OS?

Regards,
Lucas

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > -----Original Message-----
> > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > Sent: Thursday, February 13, 2020 5:16 PM
> > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > <sudeep.holla@arm.com>
> > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > 
> > Hi,
> > 
> > On 07.11.19 22:28, Adam Ford wrote:
> > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > wrote:
> > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > 
> > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > implementation, so all shared critical peripherals are solely under
> > firmware control.
> > > > > > > It might be possible to rework this to use some form of
> > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > 
> > > I was just curious to know if there is any progress being made on
> > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > the power domain support would help enable some of these features.
> > > 
> > 
> > Has there been any decision or action taken in this topic?
> > Will the power domain driver as proposed in this patch be upstreamed at
> > some time, or rather not?
> > 
> > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > and I integrated display and graphics support from the downstream NXP
> > kernel.
> > 
> > While most things already work fine, there's the issue of how to handle the
> > power domains. Currently I need to ungate some clocks in the TF-A
> > BL31 to get for example the GPU running. If I understand this correctly the
> > proposed power domain driver could handle this in Linux otherwise.
> > 
> 
> the SCMI over SMC is still under review

Even if the SCMI over SMC is ready at some point, it's still unclear to
me how you intend to abstract the GPC behind the SCMI interface in the
TF-A. The power domains have dependencies both into the regulator and
the clock framework. Both are currently under exclusive control of the
rich OS. How do you intend to allow the TF-A to control the power
supplies and necessary reset clocks without messing up any state in the
rich OS?

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 13.02.2020 13:32, Lucas Stach wrote:
> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>> -----Original Message-----
>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>> Sent: Thursday, February 13, 2020 5:16 PM
>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>> <sudeep.holla@arm.com>
>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>
>>> Hi,
>>>
>>> On 07.11.19 22:28, Adam Ford wrote:
>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>
>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>> firmware control.
>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>
>>>> I was just curious to know if there is any progress being made on
>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>> the power domain support would help enable some of these features.
>>>>
>>>
>>> Has there been any decision or action taken in this topic?
>>> Will the power domain driver as proposed in this patch be upstreamed at
>>> some time, or rather not?
>>>
>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>> and I integrated display and graphics support from the downstream NXP
>>> kernel.
>>>
>>> While most things already work fine, there's the issue of how to handle the
>>> power domains. Currently I need to ungate some clocks in the TF-A
>>> BL31 to get for example the GPU running. If I understand this correctly the
>>> proposed power domain driver could handle this in Linux otherwise.
>>>
>>
>> the SCMI over SMC is still under review
> 
> Even if the SCMI over SMC is ready at some point, it's still unclear to
> me how you intend to abstract the GPC behind the SCMI interface in the
> TF-A. The power domains have dependencies both into the regulator and
> the clock framework. Both are currently under exclusive control of the
> rich OS. How do you intend to allow the TF-A to control the power
> supplies and necessary reset clocks without messing up any state in the
> rich OS?

This is indeed difficult, SCMI assumes that the responder has sufficient 
control over clocks to fully implement power domain handling, including 
over clocks and regulators.

Perhaps it might be possible to modify current gpcv2 driver to send SCMI 
messages for power only and keep handling regulators itself? It could 
switch based on whether it has a reference to a scmi channel as a DT 
property.

A full scmi-based implementation might use entirely very different 
bindings and take a long time. If people want to support their chips by 
implementing power domain support in the rich OS we shouldn't block them.

So it would be good to accept gpcv2 enhancement for 8mm and similar.

--
Regards,
Leonard

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 13.02.2020 13:32, Lucas Stach wrote:
> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>> -----Original Message-----
>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>> Sent: Thursday, February 13, 2020 5:16 PM
>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>> <sudeep.holla@arm.com>
>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>
>>> Hi,
>>>
>>> On 07.11.19 22:28, Adam Ford wrote:
>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>
>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>> firmware control.
>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>
>>>> I was just curious to know if there is any progress being made on
>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>> the power domain support would help enable some of these features.
>>>>
>>>
>>> Has there been any decision or action taken in this topic?
>>> Will the power domain driver as proposed in this patch be upstreamed at
>>> some time, or rather not?
>>>
>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>> and I integrated display and graphics support from the downstream NXP
>>> kernel.
>>>
>>> While most things already work fine, there's the issue of how to handle the
>>> power domains. Currently I need to ungate some clocks in the TF-A
>>> BL31 to get for example the GPU running. If I understand this correctly the
>>> proposed power domain driver could handle this in Linux otherwise.
>>>
>>
>> the SCMI over SMC is still under review
> 
> Even if the SCMI over SMC is ready at some point, it's still unclear to
> me how you intend to abstract the GPC behind the SCMI interface in the
> TF-A. The power domains have dependencies both into the regulator and
> the clock framework. Both are currently under exclusive control of the
> rich OS. How do you intend to allow the TF-A to control the power
> supplies and necessary reset clocks without messing up any state in the
> rich OS?

This is indeed difficult, SCMI assumes that the responder has sufficient 
control over clocks to fully implement power domain handling, including 
over clocks and regulators.

Perhaps it might be possible to modify current gpcv2 driver to send SCMI 
messages for power only and keep handling regulators itself? It could 
switch based on whether it has a reference to a scmi channel as a DT 
property.

A full scmi-based implementation might use entirely very different 
bindings and take a long time. If people want to support their chips by 
implementing power domain support in the rich OS we shouldn't block them.

So it would be good to accept gpcv2 enhancement for 8mm and similar.

--
Regards,
Leonard

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
> On 13.02.2020 13:32, Lucas Stach wrote:
> > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > > > -----Original Message-----
> > > > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > > > <sudeep.holla@arm.com>
> > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > > > 
> > > > Hi,
> > > > 
> > > > On 07.11.19 22:28, Adam Ford wrote:
> > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > > > wrote:
> > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > > > 
> > > > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > > > implementation, so all shared critical peripherals are solely under
> > > > firmware control.
> > > > > > > > > It might be possible to rework this to use some form of
> > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > > > 
> > > > > I was just curious to know if there is any progress being made on
> > > > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > > > the power domain support would help enable some of these features.
> > > > > 
> > > > 
> > > > Has there been any decision or action taken in this topic?
> > > > Will the power domain driver as proposed in this patch be upstreamed at
> > > > some time, or rather not?
> > > > 
> > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > > > and I integrated display and graphics support from the downstream NXP
> > > > kernel.
> > > > 
> > > > While most things already work fine, there's the issue of how to handle the
> > > > power domains. Currently I need to ungate some clocks in the TF-A
> > > > BL31 to get for example the GPU running. If I understand this correctly the
> > > > proposed power domain driver could handle this in Linux otherwise.
> > > > 
> > > 
> > > the SCMI over SMC is still under review
> > 
> > Even if the SCMI over SMC is ready at some point, it's still unclear to
> > me how you intend to abstract the GPC behind the SCMI interface in the
> > TF-A. The power domains have dependencies both into the regulator and
> > the clock framework. Both are currently under exclusive control of the
> > rich OS. How do you intend to allow the TF-A to control the power
> > supplies and necessary reset clocks without messing up any state in the
> > rich OS?
> 
> This is indeed difficult, SCMI assumes that the responder has sufficient 
> control over clocks to fully implement power domain handling, including 
> over clocks and regulators.
> 
> Perhaps it might be possible to modify current gpcv2 driver to send SCMI 
> messages for power only and keep handling regulators itself? It could 
> switch based on whether it has a reference to a scmi channel as a DT 
> property.

With such a split implementation I feel like we are getting worst of
both worlds: more complexity as the implementation is split across
multiple components (TF-A and kernel) and still the rich OS is able to
mess up the power supply of a domain that it might not even own. This
doesn't sound really enticing.

IMHO it only makes sense to push this functionality down into TF-A if
it allows to abstract all the implementation details behind a standard
interface like SCMI. But then the needed changes are much more invasive
than just pushing down the GPC implementation.

> A full scmi-based implementation might use entirely very different 
> bindings and take a long time. If people want to support their chips by 
> implementing power domain support in the rich OS we shouldn't block them.
> 
> So it would be good to accept gpcv2 enhancement for 8mm and similar.

I fully agree.

For a full SCMI based implementation I expect that much more than just
the GPC functionality needs to be pushed down into the TF-A. Right now
I see clocks, i2c and regulator handling, maybe there is more that
escapes my mind.

We should not block a Linux based implementation of this functionality
on the basis that we might want to replace this with a SCMI based one
at a later point in time.

Regards,
Lucas

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
> On 13.02.2020 13:32, Lucas Stach wrote:
> > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > > > -----Original Message-----
> > > > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > > > <sudeep.holla@arm.com>
> > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > > > 
> > > > Hi,
> > > > 
> > > > On 07.11.19 22:28, Adam Ford wrote:
> > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > > > wrote:
> > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > > > 
> > > > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > > > implementation, so all shared critical peripherals are solely under
> > > > firmware control.
> > > > > > > > > It might be possible to rework this to use some form of
> > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > > > 
> > > > > I was just curious to know if there is any progress being made on
> > > > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > > > the power domain support would help enable some of these features.
> > > > > 
> > > > 
> > > > Has there been any decision or action taken in this topic?
> > > > Will the power domain driver as proposed in this patch be upstreamed at
> > > > some time, or rather not?
> > > > 
> > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > > > and I integrated display and graphics support from the downstream NXP
> > > > kernel.
> > > > 
> > > > While most things already work fine, there's the issue of how to handle the
> > > > power domains. Currently I need to ungate some clocks in the TF-A
> > > > BL31 to get for example the GPU running. If I understand this correctly the
> > > > proposed power domain driver could handle this in Linux otherwise.
> > > > 
> > > 
> > > the SCMI over SMC is still under review
> > 
> > Even if the SCMI over SMC is ready at some point, it's still unclear to
> > me how you intend to abstract the GPC behind the SCMI interface in the
> > TF-A. The power domains have dependencies both into the regulator and
> > the clock framework. Both are currently under exclusive control of the
> > rich OS. How do you intend to allow the TF-A to control the power
> > supplies and necessary reset clocks without messing up any state in the
> > rich OS?
> 
> This is indeed difficult, SCMI assumes that the responder has sufficient 
> control over clocks to fully implement power domain handling, including 
> over clocks and regulators.
> 
> Perhaps it might be possible to modify current gpcv2 driver to send SCMI 
> messages for power only and keep handling regulators itself? It could 
> switch based on whether it has a reference to a scmi channel as a DT 
> property.

With such a split implementation I feel like we are getting worst of
both worlds: more complexity as the implementation is split across
multiple components (TF-A and kernel) and still the rich OS is able to
mess up the power supply of a domain that it might not even own. This
doesn't sound really enticing.

IMHO it only makes sense to push this functionality down into TF-A if
it allows to abstract all the implementation details behind a standard
interface like SCMI. But then the needed changes are much more invasive
than just pushing down the GPC implementation.

> A full scmi-based implementation might use entirely very different 
> bindings and take a long time. If people want to support their chips by 
> implementing power domain support in the rich OS we shouldn't block them.
> 
> So it would be good to accept gpcv2 enhancement for 8mm and similar.

I fully agree.

For a full SCMI based implementation I expect that much more than just
the GPC functionality needs to be pushed down into the TF-A. Right now
I see clocks, i2c and regulator handling, maybe there is more that
escapes my mind.

We should not block a Linux based implementation of this functionality
on the basis that we might want to replace this with a SCMI based one
at a later point in time.

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 13.02.2020 16:47, Lucas Stach wrote:
> On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
>> On 13.02.2020 13:32, Lucas Stach wrote:
>>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>>>> -----Original Message-----
>>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>>>> <sudeep.holla@arm.com>
>>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 07.11.19 22:28, Adam Ford wrote:
>>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>>>
>>>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>>>> firmware control.
>>>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>>>
>>>>>> I was just curious to know if there is any progress being made on
>>>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>>>> the power domain support would help enable some of these features.
>>>>>>
>>>>>
>>>>> Has there been any decision or action taken in this topic?
>>>>> Will the power domain driver as proposed in this patch be upstreamed at
>>>>> some time, or rather not?
>>>>>
>>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>>>> and I integrated display and graphics support from the downstream NXP
>>>>> kernel.
>>>>>
>>>>> While most things already work fine, there's the issue of how to handle the
>>>>> power domains. Currently I need to ungate some clocks in the TF-A
>>>>> BL31 to get for example the GPU running. If I understand this correctly the
>>>>> proposed power domain driver could handle this in Linux otherwise.
>>>>>
>>>>
>>>> the SCMI over SMC is still under review
>>>
>>> Even if the SCMI over SMC is ready at some point, it's still unclear to
>>> me how you intend to abstract the GPC behind the SCMI interface in the
>>> TF-A. The power domains have dependencies both into the regulator and
>>> the clock framework. Both are currently under exclusive control of the
>>> rich OS. How do you intend to allow the TF-A to control the power
>>> supplies and necessary reset clocks without messing up any state in the
>>> rich OS?
>>
>> This is indeed difficult, SCMI assumes that the responder has sufficient
>> control over clocks to fully implement power domain handling, including
>> over clocks and regulators.
>>
>> Perhaps it might be possible to modify current gpcv2 driver to send SCMI
>> messages for power only and keep handling regulators itself? It could
>> switch based on whether it has a reference to a scmi channel as a DT
>> property.
> 
> With such a split implementation I feel like we are getting worst of
> both worlds: more complexity as the implementation is split across
> multiple components (TF-A and kernel) and still the rich OS is able to
> mess up the power supply of a domain that it might not even own. This
> doesn't sound really enticing.
> 
> IMHO it only makes sense to push this functionality down into TF-A if
> it allows to abstract all the implementation details behind a standard
> interface like SCMI. But then the needed changes are much more invasive
> than just pushing down the GPC implementation.
> 
>> A full scmi-based implementation might use entirely very different
>> bindings and take a long time. If people want to support their chips by
>> implementing power domain support in the rich OS we shouldn't block them.
>>
>> So it would be good to accept gpcv2 enhancement for 8mm and similar.
> 
> I fully agree.
> 
> For a full SCMI based implementation I expect that much more than just
> the GPC functionality needs to be pushed down into the TF-A. Right now
> I see clocks, i2c and regulator handling, maybe there is more that
> escapes my mind.

I2C regulator handling inside TF-A sounds very difficult. Not only would 
upstream TF-A likely object but on imx8m EVK boards the i2c bus for 
regulators is shared with other devices (like camera).

So if we do this maybe SCMI dt bindings could be expanded to at least 
allow regulators on a per-domain basis?

> We should not block a Linux based implementation of this functionality
> on the basis that we might want to replace this with a SCMI based one
> at a later point in time.

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Leonard Crestez]

On 13.02.2020 16:47, Lucas Stach wrote:
> On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
>> On 13.02.2020 13:32, Lucas Stach wrote:
>>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>>>> -----Original Message-----
>>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>>>> <sudeep.holla@arm.com>
>>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 07.11.19 22:28, Adam Ford wrote:
>>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>>>
>>>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>>>> firmware control.
>>>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>>>
>>>>>> I was just curious to know if there is any progress being made on
>>>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>>>> the power domain support would help enable some of these features.
>>>>>>
>>>>>
>>>>> Has there been any decision or action taken in this topic?
>>>>> Will the power domain driver as proposed in this patch be upstreamed at
>>>>> some time, or rather not?
>>>>>
>>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>>>> and I integrated display and graphics support from the downstream NXP
>>>>> kernel.
>>>>>
>>>>> While most things already work fine, there's the issue of how to handle the
>>>>> power domains. Currently I need to ungate some clocks in the TF-A
>>>>> BL31 to get for example the GPU running. If I understand this correctly the
>>>>> proposed power domain driver could handle this in Linux otherwise.
>>>>>
>>>>
>>>> the SCMI over SMC is still under review
>>>
>>> Even if the SCMI over SMC is ready at some point, it's still unclear to
>>> me how you intend to abstract the GPC behind the SCMI interface in the
>>> TF-A. The power domains have dependencies both into the regulator and
>>> the clock framework. Both are currently under exclusive control of the
>>> rich OS. How do you intend to allow the TF-A to control the power
>>> supplies and necessary reset clocks without messing up any state in the
>>> rich OS?
>>
>> This is indeed difficult, SCMI assumes that the responder has sufficient
>> control over clocks to fully implement power domain handling, including
>> over clocks and regulators.
>>
>> Perhaps it might be possible to modify current gpcv2 driver to send SCMI
>> messages for power only and keep handling regulators itself? It could
>> switch based on whether it has a reference to a scmi channel as a DT
>> property.
> 
> With such a split implementation I feel like we are getting worst of
> both worlds: more complexity as the implementation is split across
> multiple components (TF-A and kernel) and still the rich OS is able to
> mess up the power supply of a domain that it might not even own. This
> doesn't sound really enticing.
> 
> IMHO it only makes sense to push this functionality down into TF-A if
> it allows to abstract all the implementation details behind a standard
> interface like SCMI. But then the needed changes are much more invasive
> than just pushing down the GPC implementation.
> 
>> A full scmi-based implementation might use entirely very different
>> bindings and take a long time. If people want to support their chips by
>> implementing power domain support in the rich OS we shouldn't block them.
>>
>> So it would be good to accept gpcv2 enhancement for 8mm and similar.
> 
> I fully agree.
> 
> For a full SCMI based implementation I expect that much more than just
> the GPC functionality needs to be pushed down into the TF-A. Right now
> I see clocks, i2c and regulator handling, maybe there is more that
> escapes my mind.

I2C regulator handling inside TF-A sounds very difficult. Not only would 
upstream TF-A likely object but on imx8m EVK boards the i2c bus for 
regulators is shared with other devices (like camera).

So if we do this maybe SCMI dt bindings could be expanded to at least 
allow regulators on a per-domain basis?

> We should not block a Linux based implementation of this functionality
> on the basis that we might want to replace this with a SCMI based one
> at a later point in time.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote:
> On 13.02.2020 16:47, Lucas Stach wrote:
> > On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
> > > On 13.02.2020 13:32, Lucas Stach wrote:
> > > > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > > > > > -----Original Message-----
> > > > > > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > > > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > > > > > <sudeep.holla@arm.com>
> > > > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > > > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > > > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > > > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > > > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > > > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > > > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > > > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > > > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > > > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > On 07.11.19 22:28, Adam Ford wrote:
> > > > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > > > > > wrote:
> > > > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > > > > > 
> > > > > > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > > > > > implementation, so all shared critical peripherals are solely under
> > > > > > firmware control.
> > > > > > > > > > > It might be possible to rework this to use some form of
> > > > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > > > > > 
> > > > > > > I was just curious to know if there is any progress being made on
> > > > > > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > > > > > the power domain support would help enable some of these features.
> > > > > > > 
> > > > > > 
> > > > > > Has there been any decision or action taken in this topic?
> > > > > > Will the power domain driver as proposed in this patch be upstreamed at
> > > > > > some time, or rather not?
> > > > > > 
> > > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > > > > > and I integrated display and graphics support from the downstream NXP
> > > > > > kernel.
> > > > > > 
> > > > > > While most things already work fine, there's the issue of how to handle the
> > > > > > power domains. Currently I need to ungate some clocks in the TF-A
> > > > > > BL31 to get for example the GPU running. If I understand this correctly the
> > > > > > proposed power domain driver could handle this in Linux otherwise.
> > > > > > 
> > > > > 
> > > > > the SCMI over SMC is still under review
> > > > 
> > > > Even if the SCMI over SMC is ready at some point, it's still unclear to
> > > > me how you intend to abstract the GPC behind the SCMI interface in the
> > > > TF-A. The power domains have dependencies both into the regulator and
> > > > the clock framework. Both are currently under exclusive control of the
> > > > rich OS. How do you intend to allow the TF-A to control the power
> > > > supplies and necessary reset clocks without messing up any state in the
> > > > rich OS?
> > > 
> > > This is indeed difficult, SCMI assumes that the responder has sufficient
> > > control over clocks to fully implement power domain handling, including
> > > over clocks and regulators.
> > > 
> > > Perhaps it might be possible to modify current gpcv2 driver to send SCMI
> > > messages for power only and keep handling regulators itself? It could
> > > switch based on whether it has a reference to a scmi channel as a DT
> > > property.
> > 
> > With such a split implementation I feel like we are getting worst of
> > both worlds: more complexity as the implementation is split across
> > multiple components (TF-A and kernel) and still the rich OS is able to
> > mess up the power supply of a domain that it might not even own. This
> > doesn't sound really enticing.
> > 
> > IMHO it only makes sense to push this functionality down into TF-A if
> > it allows to abstract all the implementation details behind a standard
> > interface like SCMI. But then the needed changes are much more invasive
> > than just pushing down the GPC implementation.
> > 
> > > A full scmi-based implementation might use entirely very different
> > > bindings and take a long time. If people want to support their chips by
> > > implementing power domain support in the rich OS we shouldn't block them.
> > > 
> > > So it would be good to accept gpcv2 enhancement for 8mm and similar.
> > 
> > I fully agree.
> > 
> > For a full SCMI based implementation I expect that much more than just
> > the GPC functionality needs to be pushed down into the TF-A. Right now
> > I see clocks, i2c and regulator handling, maybe there is more that
> > escapes my mind.
> 
> I2C regulator handling inside TF-A sounds very difficult. Not only would 
> upstream TF-A likely object but on imx8m EVK boards the i2c bus for 
> regulators is shared with other devices (like camera).

And that's exactly the point where trying to push things into lower
layers starts to crumble. It only really makes sense if you manage to
establish a nice abstraction of what is happening in those lower
layers. If you need to punch through those abstractions due to system
design limitations, the benefit of those abstractions is wiped away.
The only thing you gain is more complexity due to more components being
involved in a specific task.

If you want to be able to partition the system (and as far as I
understand it that's the main motivation for pushing GPC functionality
into TF-A) you need to design the system (starting on the HW level) to
make this possible. Trying to force such a model on a system that
hasn't really been designed for this is IMHO doomed to fail.

> So if we do this maybe SCMI dt bindings could be expanded to at least 
> allow regulators on a per-domain basis?

Maybe that is what needs to be done to allow at least a partial
implementation of SCMI on the existing i.MX8M designs. However it
doesn't really provide much of the benefits of SCMI.

So I'm all for having a pure Linux based implementation of the
functionality, instead of waiting for the SCMI based implementation
that may provide only questionable benefit.

Regards,
Lucas

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Lucas Stach]

On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote:
> On 13.02.2020 16:47, Lucas Stach wrote:
> > On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
> > > On 13.02.2020 13:32, Lucas Stach wrote:
> > > > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > > > > > -----Original Message-----
> > > > > > From: Schrempf Frieder <frieder.schrempf@kontron.de>
> > > > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla
> > > > > > <sudeep.holla@arm.com>
> > > > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
> > > > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty
> > > > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
> > > > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
> > > > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
> > > > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
> > > > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
> > > > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
> > > > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
> > > > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > On 07.11.19 22:28, Adam Ford wrote:
> > > > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
> > > > > > wrote:
> > > > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > > > > > > > > > > > I don't yet buy the security argument. There are many more shared
> > > > > > > > > > > > parts on the SoC, like the clock controller, that would need to
> > > > > > > > > > > > be taken away from the non-secure world if one would want to run
> > > > > > > > > > > > an untrusted OS kernel on a i.MX8M system.
> > > > > > > > > > > > 
> > > > > > > > > > > > To properly implement security on any i.MX8M based system the
> > > > > > > > > > > > firmware would need to grow something like a full ARM SCPI
> > > > > > > > > > > > implementation, so all shared critical peripherals are solely under
> > > > > > firmware control.
> > > > > > > > > > > It might be possible to rework this to use some form of
> > > > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > > > > > > 
> > > > > > > I was just curious to know if there is any progress being made on
> > > > > > > this.  The i.mx8mm-evk is missing functionality upstream and I think
> > > > > > > the power domain support would help enable some of these features.
> > > > > > > 
> > > > > > 
> > > > > > Has there been any decision or action taken in this topic?
> > > > > > Will the power domain driver as proposed in this patch be upstreamed at
> > > > > > some time, or rather not?
> > > > > > 
> > > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
> > > > > > and I integrated display and graphics support from the downstream NXP
> > > > > > kernel.
> > > > > > 
> > > > > > While most things already work fine, there's the issue of how to handle the
> > > > > > power domains. Currently I need to ungate some clocks in the TF-A
> > > > > > BL31 to get for example the GPU running. If I understand this correctly the
> > > > > > proposed power domain driver could handle this in Linux otherwise.
> > > > > > 
> > > > > 
> > > > > the SCMI over SMC is still under review
> > > > 
> > > > Even if the SCMI over SMC is ready at some point, it's still unclear to
> > > > me how you intend to abstract the GPC behind the SCMI interface in the
> > > > TF-A. The power domains have dependencies both into the regulator and
> > > > the clock framework. Both are currently under exclusive control of the
> > > > rich OS. How do you intend to allow the TF-A to control the power
> > > > supplies and necessary reset clocks without messing up any state in the
> > > > rich OS?
> > > 
> > > This is indeed difficult, SCMI assumes that the responder has sufficient
> > > control over clocks to fully implement power domain handling, including
> > > over clocks and regulators.
> > > 
> > > Perhaps it might be possible to modify current gpcv2 driver to send SCMI
> > > messages for power only and keep handling regulators itself? It could
> > > switch based on whether it has a reference to a scmi channel as a DT
> > > property.
> > 
> > With such a split implementation I feel like we are getting worst of
> > both worlds: more complexity as the implementation is split across
> > multiple components (TF-A and kernel) and still the rich OS is able to
> > mess up the power supply of a domain that it might not even own. This
> > doesn't sound really enticing.
> > 
> > IMHO it only makes sense to push this functionality down into TF-A if
> > it allows to abstract all the implementation details behind a standard
> > interface like SCMI. But then the needed changes are much more invasive
> > than just pushing down the GPC implementation.
> > 
> > > A full scmi-based implementation might use entirely very different
> > > bindings and take a long time. If people want to support their chips by
> > > implementing power domain support in the rich OS we shouldn't block them.
> > > 
> > > So it would be good to accept gpcv2 enhancement for 8mm and similar.
> > 
> > I fully agree.
> > 
> > For a full SCMI based implementation I expect that much more than just
> > the GPC functionality needs to be pushed down into the TF-A. Right now
> > I see clocks, i2c and regulator handling, maybe there is more that
> > escapes my mind.
> 
> I2C regulator handling inside TF-A sounds very difficult. Not only would 
> upstream TF-A likely object but on imx8m EVK boards the i2c bus for 
> regulators is shared with other devices (like camera).

And that's exactly the point where trying to push things into lower
layers starts to crumble. It only really makes sense if you manage to
establish a nice abstraction of what is happening in those lower
layers. If you need to punch through those abstractions due to system
design limitations, the benefit of those abstractions is wiped away.
The only thing you gain is more complexity due to more components being
involved in a specific task.

If you want to be able to partition the system (and as far as I
understand it that's the main motivation for pushing GPC functionality
into TF-A) you need to design the system (starting on the HW level) to
make this possible. Trying to force such a model on a system that
hasn't really been designed for this is IMHO doomed to fail.

> So if we do this maybe SCMI dt bindings could be expanded to at least 
> allow regulators on a per-domain basis?

Maybe that is what needs to be done to allow at least a partial
implementation of SCMI on the existing i.MX8M designs. However it
doesn't really provide much of the benefits of SCMI.

So I'm all for having a pure Linux based implementation of the
functionality, instead of waiting for the SCMI based implementation
that may provide only questionable benefit.

Regards,
Lucas


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

On 13.02.20 16:58, Lucas Stach wrote:
> On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote:
>> On 13.02.2020 16:47, Lucas Stach wrote:
>>> On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
>>>> On 13.02.2020 13:32, Lucas Stach wrote:
>>>>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>>>>>> <sudeep.holla@arm.com>
>>>>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>>>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>>>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>>>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>>>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>>>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>>>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>>>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 07.11.19 22:28, Adam Ford wrote:
>>>>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>>>>>> wrote:
>>>>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>>>>>> firmware control.
>>>>>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>>>>>
>>>>>>>> I was just curious to know if there is any progress being made on
>>>>>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>>>>>> the power domain support would help enable some of these features.
>>>>>>>>
>>>>>>>
>>>>>>> Has there been any decision or action taken in this topic?
>>>>>>> Will the power domain driver as proposed in this patch be upstreamed at
>>>>>>> some time, or rather not?
>>>>>>>
>>>>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>>>>>> and I integrated display and graphics support from the downstream NXP
>>>>>>> kernel.
>>>>>>>
>>>>>>> While most things already work fine, there's the issue of how to handle the
>>>>>>> power domains. Currently I need to ungate some clocks in the TF-A
>>>>>>> BL31 to get for example the GPU running. If I understand this correctly the
>>>>>>> proposed power domain driver could handle this in Linux otherwise.
>>>>>>>
>>>>>>
>>>>>> the SCMI over SMC is still under review
>>>>>
>>>>> Even if the SCMI over SMC is ready at some point, it's still unclear to
>>>>> me how you intend to abstract the GPC behind the SCMI interface in the
>>>>> TF-A. The power domains have dependencies both into the regulator and
>>>>> the clock framework. Both are currently under exclusive control of the
>>>>> rich OS. How do you intend to allow the TF-A to control the power
>>>>> supplies and necessary reset clocks without messing up any state in the
>>>>> rich OS?
>>>>
>>>> This is indeed difficult, SCMI assumes that the responder has sufficient
>>>> control over clocks to fully implement power domain handling, including
>>>> over clocks and regulators.
>>>>
>>>> Perhaps it might be possible to modify current gpcv2 driver to send SCMI
>>>> messages for power only and keep handling regulators itself? It could
>>>> switch based on whether it has a reference to a scmi channel as a DT
>>>> property.
>>>
>>> With such a split implementation I feel like we are getting worst of
>>> both worlds: more complexity as the implementation is split across
>>> multiple components (TF-A and kernel) and still the rich OS is able to
>>> mess up the power supply of a domain that it might not even own. This
>>> doesn't sound really enticing.
>>>
>>> IMHO it only makes sense to push this functionality down into TF-A if
>>> it allows to abstract all the implementation details behind a standard
>>> interface like SCMI. But then the needed changes are much more invasive
>>> than just pushing down the GPC implementation.
>>>
>>>> A full scmi-based implementation might use entirely very different
>>>> bindings and take a long time. If people want to support their chips by
>>>> implementing power domain support in the rich OS we shouldn't block them.
>>>>
>>>> So it would be good to accept gpcv2 enhancement for 8mm and similar.
>>>
>>> I fully agree.
>>>
>>> For a full SCMI based implementation I expect that much more than just
>>> the GPC functionality needs to be pushed down into the TF-A. Right now
>>> I see clocks, i2c and regulator handling, maybe there is more that
>>> escapes my mind.
>>
>> I2C regulator handling inside TF-A sounds very difficult. Not only would
>> upstream TF-A likely object but on imx8m EVK boards the i2c bus for
>> regulators is shared with other devices (like camera).
> 
> And that's exactly the point where trying to push things into lower
> layers starts to crumble. It only really makes sense if you manage to
> establish a nice abstraction of what is happening in those lower
> layers. If you need to punch through those abstractions due to system
> design limitations, the benefit of those abstractions is wiped away.
> The only thing you gain is more complexity due to more components being
> involved in a specific task.
> 
> If you want to be able to partition the system (and as far as I
> understand it that's the main motivation for pushing GPC functionality
> into TF-A) you need to design the system (starting on the HW level) to
> make this possible. Trying to force such a model on a system that
> hasn't really been designed for this is IMHO doomed to fail.
> 
>> So if we do this maybe SCMI dt bindings could be expanded to at least
>> allow regulators on a per-domain basis?
> 
> Maybe that is what needs to be done to allow at least a partial
> implementation of SCMI on the existing i.MX8M designs. However it
> doesn't really provide much of the benefits of SCMI.
> 
> So I'm all for having a pure Linux based implementation of the
> functionality, instead of waiting for the SCMI based implementation
> that may provide only questionable benefit.

After reading through the thread and other resources - with still very 
limited knowledge - I tend to support Lucas' argument.

We want to provide a mainline BSP for our i.MX8MM hardware and it seems 
like pushing more and more functionality from Linux into firmware will 
increase complexity even further and also delay or block the upstreaming 
of missing components, that would otherwise be rather easy to get running.

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Schrempf Frieder]

On 13.02.20 16:58, Lucas Stach wrote:
> On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote:
>> On 13.02.2020 16:47, Lucas Stach wrote:
>>> On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote:
>>>> On 13.02.2020 13:32, Lucas Stach wrote:
>>>>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de>
>>>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla
>>>>>>> <sudeep.holla@arm.com>
>>>>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng
>>>>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty
>>>>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>;
>>>>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara
>>>>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>;
>>>>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com;
>>>>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de>
>>>>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 07.11.19 22:28, Adam Ford wrote:
>>>>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com>
>>>>>>> wrote:
>>>>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
>>>>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote:
>>>>>>>>>>>>> I don't yet buy the security argument. There are many more shared
>>>>>>>>>>>>> parts on the SoC, like the clock controller, that would need to
>>>>>>>>>>>>> be taken away from the non-secure world if one would want to run
>>>>>>>>>>>>> an untrusted OS kernel on a i.MX8M system.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To properly implement security on any i.MX8M based system the
>>>>>>>>>>>>> firmware would need to grow something like a full ARM SCPI
>>>>>>>>>>>>> implementation, so all shared critical peripherals are solely under
>>>>>>> firmware control.
>>>>>>>>>>>> It might be possible to rework this to use some form of
>>>>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
>>>>>>>>
>>>>>>>> I was just curious to know if there is any progress being made on
>>>>>>>> this.  The i.mx8mm-evk is missing functionality upstream and I think
>>>>>>>> the power domain support would help enable some of these features.
>>>>>>>>
>>>>>>>
>>>>>>> Has there been any decision or action taken in this topic?
>>>>>>> Will the power domain driver as proposed in this patch be upstreamed at
>>>>>>> some time, or rather not?
>>>>>>>
>>>>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux)
>>>>>>> and I integrated display and graphics support from the downstream NXP
>>>>>>> kernel.
>>>>>>>
>>>>>>> While most things already work fine, there's the issue of how to handle the
>>>>>>> power domains. Currently I need to ungate some clocks in the TF-A
>>>>>>> BL31 to get for example the GPU running. If I understand this correctly the
>>>>>>> proposed power domain driver could handle this in Linux otherwise.
>>>>>>>
>>>>>>
>>>>>> the SCMI over SMC is still under review
>>>>>
>>>>> Even if the SCMI over SMC is ready at some point, it's still unclear to
>>>>> me how you intend to abstract the GPC behind the SCMI interface in the
>>>>> TF-A. The power domains have dependencies both into the regulator and
>>>>> the clock framework. Both are currently under exclusive control of the
>>>>> rich OS. How do you intend to allow the TF-A to control the power
>>>>> supplies and necessary reset clocks without messing up any state in the
>>>>> rich OS?
>>>>
>>>> This is indeed difficult, SCMI assumes that the responder has sufficient
>>>> control over clocks to fully implement power domain handling, including
>>>> over clocks and regulators.
>>>>
>>>> Perhaps it might be possible to modify current gpcv2 driver to send SCMI
>>>> messages for power only and keep handling regulators itself? It could
>>>> switch based on whether it has a reference to a scmi channel as a DT
>>>> property.
>>>
>>> With such a split implementation I feel like we are getting worst of
>>> both worlds: more complexity as the implementation is split across
>>> multiple components (TF-A and kernel) and still the rich OS is able to
>>> mess up the power supply of a domain that it might not even own. This
>>> doesn't sound really enticing.
>>>
>>> IMHO it only makes sense to push this functionality down into TF-A if
>>> it allows to abstract all the implementation details behind a standard
>>> interface like SCMI. But then the needed changes are much more invasive
>>> than just pushing down the GPC implementation.
>>>
>>>> A full scmi-based implementation might use entirely very different
>>>> bindings and take a long time. If people want to support their chips by
>>>> implementing power domain support in the rich OS we shouldn't block them.
>>>>
>>>> So it would be good to accept gpcv2 enhancement for 8mm and similar.
>>>
>>> I fully agree.
>>>
>>> For a full SCMI based implementation I expect that much more than just
>>> the GPC functionality needs to be pushed down into the TF-A. Right now
>>> I see clocks, i2c and regulator handling, maybe there is more that
>>> escapes my mind.
>>
>> I2C regulator handling inside TF-A sounds very difficult. Not only would
>> upstream TF-A likely object but on imx8m EVK boards the i2c bus for
>> regulators is shared with other devices (like camera).
> 
> And that's exactly the point where trying to push things into lower
> layers starts to crumble. It only really makes sense if you manage to
> establish a nice abstraction of what is happening in those lower
> layers. If you need to punch through those abstractions due to system
> design limitations, the benefit of those abstractions is wiped away.
> The only thing you gain is more complexity due to more components being
> involved in a specific task.
> 
> If you want to be able to partition the system (and as far as I
> understand it that's the main motivation for pushing GPC functionality
> into TF-A) you need to design the system (starting on the HW level) to
> make this possible. Trying to force such a model on a system that
> hasn't really been designed for this is IMHO doomed to fail.
> 
>> So if we do this maybe SCMI dt bindings could be expanded to at least
>> allow regulators on a per-domain basis?
> 
> Maybe that is what needs to be done to allow at least a partial
> implementation of SCMI on the existing i.MX8M designs. However it
> doesn't really provide much of the benefits of SCMI.
> 
> So I'm all for having a pure Linux based implementation of the
> functionality, instead of waiting for the SCMI based implementation
> that may provide only questionable benefit.

After reading through the thread and other resources - with still very 
limited knowledge - I tend to support Lucas' argument.

We want to provide a mainline BSP for our i.MX8MM hardware and it seems 
like pushing more and more functionality from Linux into firmware will 
increase complexity even further and also delay or block the upstreaming 
of missing components, that would otherwise be rather easy to get running.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On 17/04/2019 13:13, Lucas Stach wrote:
> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
>>> From: Jacky Bai
>>> Sent: Wednesday, April 17, 2019 1:27 PM
>>>
>>> The i.MX8M family is a set of NXP product focus on delivering the latest and
>>> greatest video and audio experience combining state-of-the-art media-specific
>>> features with high-performance processing while optimized for lowest power
>>> consumption.
>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
>>> this family.
>>>
>>> The GPC module is used to manage the PU power domains' power on/off. For
>>> the whole i.MX8M family, different SoC has differnt power domain design. the
>>> power up sequence has significant difference.
>>> all the power sequence must be guaranteed by SW. Some domains' power up
>>> sequence need to access the SRC module or sub-system specific GPR.
>>> the SRC register & SS's register are not in in the GPC's memory range.
>>>
>>> it makes us hard to use the GPCv2 driver to cover all the different power up
>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
>>> self-contained. Accessing the non-driver specific module's register is a bad
>>> practice. Although, the GPC module provided the similar function for PU power
>>> domain, but it is not 100% compatible with GPCv2.
>>>
>>> The most important thing is that the GPC & SRC module is a security critical
>>> resource that security permission must be considered when building the
>>> security system. The GPC module is not only used by PU power domain power
>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power
>>> management. the SRC module control the CPU CORE reset and the CPU reset
>>> vector address. if we give the non-secure world write permission to SRC.
>>> System can be easily induced to malicious code.
>>>
>>
>> Considering the security issue, it looks to me a right direction to move GPC
>> power handling into ATF.
>> It also helps build a more generic driver and ease other OS integration
>> needed by customers (e.g. QNX, Win10).
>>
>> Lucas,
>> How do you think of it?
>
> I don't yet buy the security argument. There are many more shared parts
> on the SoC, like the clock controller, that would need to be taken away
> from the non-secure world if one would want to run an untrusted OS
> kernel on a i.MX8M system.
>
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so
> all shared critical peripherals are solely under firmware control.
>
> I agree that it might make sense to move some parts into the firmware
> and have much simpler OS level drivers, but I don't agree on the
> implementation direction taken here. Growing custom PSCI extension
> interfaces will only get us so far, without solving the system security
> issue in a holistic way. It is my strong believe that only a complete
> rearchitecture of the OS support on top of a ARM SCPI firmware
> interface can solve this properly.
>

+1 for all the above.

For me, though the intention looks good, this implementation is half
cooked and just creating more mess with lots of custom SMC extensions.
You can use them in products, but I would not like in upstream which is
more focused on long term maintenance.

--
Regards,
Sudeep



--
Regards,
Sudeep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On 17/04/2019 13:13, Lucas Stach wrote:
> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
>>> From: Jacky Bai
>>> Sent: Wednesday, April 17, 2019 1:27 PM
>>>
>>> The i.MX8M family is a set of NXP product focus on delivering the latest and
>>> greatest video and audio experience combining state-of-the-art media-specific
>>> features with high-performance processing while optimized for lowest power
>>> consumption.
>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to
>>> this family.
>>>
>>> The GPC module is used to manage the PU power domains' power on/off. For
>>> the whole i.MX8M family, different SoC has differnt power domain design. the
>>> power up sequence has significant difference.
>>> all the power sequence must be guaranteed by SW. Some domains' power up
>>> sequence need to access the SRC module or sub-system specific GPR.
>>> the SRC register & SS's register are not in in the GPC's memory range.
>>>
>>> it makes us hard to use the GPCv2 driver to cover all the different power up
>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver
>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it.
>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be
>>> self-contained. Accessing the non-driver specific module's register is a bad
>>> practice. Although, the GPC module provided the similar function for PU power
>>> domain, but it is not 100% compatible with GPCv2.
>>>
>>> The most important thing is that the GPC & SRC module is a security critical
>>> resource that security permission must be considered when building the
>>> security system. The GPC module is not only used by PU power domain power
>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power
>>> management. the SRC module control the CPU CORE reset and the CPU reset
>>> vector address. if we give the non-secure world write permission to SRC.
>>> System can be easily induced to malicious code.
>>>
>>
>> Considering the security issue, it looks to me a right direction to move GPC
>> power handling into ATF.
>> It also helps build a more generic driver and ease other OS integration
>> needed by customers (e.g. QNX, Win10).
>>
>> Lucas,
>> How do you think of it?
>
> I don't yet buy the security argument. There are many more shared parts
> on the SoC, like the clock controller, that would need to be taken away
> from the non-secure world if one would want to run an untrusted OS
> kernel on a i.MX8M system.
>
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so
> all shared critical peripherals are solely under firmware control.
>
> I agree that it might make sense to move some parts into the firmware
> and have much simpler OS level drivers, but I don't agree on the
> implementation direction taken here. Growing custom PSCI extension
> interfaces will only get us so far, without solving the system security
> issue in a holistic way. It is my strong believe that only a complete
> rearchitecture of the OS support on top of a ARM SCPI firmware
> interface can solve this properly.
>

+1 for all the above.

For me, though the intention looks good, this implementation is half
cooked and just creating more mess with lots of custom SMC extensions.
You can use them in products, but I would not like in upstream which is
more focused on long term maintenance.

--
Regards,
Sudeep



--
Regards,
Sudeep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 2:23 PM Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>

[...]

> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Sorry, the above disclaimer was completely unintentional. I must have
done something by mistake
for this to happen once in series of replies on this thread.

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 2:23 PM Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>

[...]

> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Sorry, the above disclaimer was completely unintentional. I must have
done something by mistake
for this to happen once in series of replies on this thread.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

> > > From: Jacky Bai
> > > Sent: Wednesday, April 17, 2019 1:27 PM
> > >
> > > The i.MX8M family is a set of NXP product focus on delivering the
> > > latest and greatest video and audio experience combining
> > > state-of-the-art media-specific features with high-performance
> > > processing while optimized for lowest power consumption.
> > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong
> > > to this family.
> > >
> > > The GPC module is used to manage the PU power domains' power on/off.
> > > For the whole i.MX8M family, different SoC has differnt power domain
> > > design. the power up sequence has significant difference.
> > > all the power sequence must be guaranteed by SW. Some domains' power
> > > up sequence need to access the SRC module or sub-system specific GPR.
> > > the SRC register & SS's register are not in in the GPC's memory range.
> > >
> > > it makes us hard to use the GPCv2 driver to cover all the different
> > > power up requirement. Each time, a new SoC is added, we must modify
> > > the GPCv2 driver to make it resuable for it. a lot of code need to be added
> in GPCv2 to support it.
> > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT
> > > be self-contained. Accessing the non-driver specific module's
> > > register is a bad practice. Although, the GPC module provided the
> > > similar function for PU power domain, but it is not 100% compatible with
> GPCv2.
> > >
> > > The most important thing is that the GPC & SRC module is a security
> > > critical resource that security permission must be considered when
> > > building the security system. The GPC module is not only used by PU
> > > power domain power on/off. It is also used by the TF-A PSCI code to
> > > do the CPU core power management. the SRC module control the CPU
> > > CORE reset and the CPU reset vector address. if we give the non-secure
> world write permission to SRC.
> > > System can be easily induced to malicious code.
> > >
> >
> > Considering the security issue, it looks to me a right direction to
> > move GPC power handling into ATF.
> > It also helps build a more generic driver and ease other OS
> > integration needed by customers (e.g. QNX, Win10).
> >
> > Lucas,
> > How do you think of it?
> 
> I don't yet buy the security argument. There are many more shared parts on
> the SoC, like the clock controller, that would need to be taken away from the
> non-secure world if one would want to run an untrusted OS kernel on a
> i.MX8M system.
> 
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so all
> shared critical peripherals are solely under firmware control.
> 
> I agree that it might make sense to move some parts into the firmware and
> have much simpler OS level drivers, but I don't agree on the implementation
> direction taken here. Growing custom PSCI extension interfaces will only get
> us so far, without solving the system security issue in a holistic way. It is my
> strong believe that only a complete rearchitecture of the OS support on top of
> a ARM SCPI firmware interface can solve this properly.
> 

No plan to implement SCPI like firmware on i.MX8M. i.MX8M don't

BR
Jacky Bai

> Regards,
> Lucas

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong:
> > > From: Jacky Bai
> > > Sent: Wednesday, April 17, 2019 1:27 PM
> > >
> > > The i.MX8M family is a set of NXP product focus on delivering the
> > > latest and greatest video and audio experience combining
> > > state-of-the-art media-specific features with high-performance
> > > processing while optimized for lowest power consumption.
> > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong
> > > to this family.
> > >
> > > The GPC module is used to manage the PU power domains' power on/off.
> > > For the whole i.MX8M family, different SoC has differnt power domain
> > > design. the power up sequence has significant difference.
> > > all the power sequence must be guaranteed by SW. Some domains' power
> > > up sequence need to access the SRC module or sub-system specific GPR.
> > > the SRC register & SS's register are not in in the GPC's memory range.
> > >
> > > it makes us hard to use the GPCv2 driver to cover all the different
> > > power up requirement. Each time, a new SoC is added, we must modify
> > > the GPCv2 driver to make it resuable for it. a lot of code need to be added
> in GPCv2 to support it.
> > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT
> > > be self-contained. Accessing the non-driver specific module's
> > > register is a bad practice. Although, the GPC module provided the
> > > similar function for PU power domain, but it is not 100% compatible with
> GPCv2.
> > >
> > > The most important thing is that the GPC & SRC module is a security
> > > critical resource that security permission must be considered when
> > > building the security system. The GPC module is not only used by PU
> > > power domain power on/off. It is also used by the TF-A PSCI code to
> > > do the CPU core power management. the SRC module control the CPU
> > > CORE reset and the CPU reset vector address. if we give the non-secure
> world write permission to SRC.
> > > System can be easily induced to malicious code.
> > >
> >
> > Considering the security issue, it looks to me a right direction to
> > move GPC power handling into ATF.
> > It also helps build a more generic driver and ease other OS
> > integration needed by customers (e.g. QNX, Win10).
> >
> > Lucas,
> > How do you think of it?
> 
> I don't yet buy the security argument. There are many more shared parts on
> the SoC, like the clock controller, that would need to be taken away from the
> non-secure world if one would want to run an untrusted OS kernel on a
> i.MX8M system.
> 
> To properly implement security on any i.MX8M based system the firmware
> would need to grow something like a full ARM SCPI implementation, so all
> shared critical peripherals are solely under firmware control.
> 
> I agree that it might make sense to move some parts into the firmware and
> have much simpler OS level drivers, but I don't agree on the implementation
> direction taken here. Growing custom PSCI extension interfaces will only get
> us so far, without solving the system security issue in a holistic way. It is my
> strong believe that only a complete rearchitecture of the OS support on top of
> a ARM SCPI firmware interface can solve this properly.
> 

Hi Lucas,

Either SCMI or SCPI, I think it is initially designed for SOC that has dedicated SCP to
manage the SOC resource, but for i.MX8M, we don't have such support. so just
for the power domain support, do you have other suggestion for it.

BR
Jacky Bai

> Regards,
> Lucas

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 02:30:53PM +0000, Jacky Bai wrote:
>
> Hi Lucas,
>
> Either SCMI or SCPI, I think it is initially designed for SOC that has
> dedicated SCP to manage the SOC resource, but for i.MX8M, we don't have such
> support. so just for the power domain support, do you have other suggestion
> for it.
>

I disagree, I thought it was clear from my earlier email. All OSPM like
Linux kernel cares is conformance to the interface. And SCMI/SCPI kind
of interface doesn't mandate how to implement either at the hardware
(you may or may not have dedicated processor) or software level(can do
it in TF-A through SMC, or some remote process through mailbox)

I am clearly against the custom SMC:

1. It will never end and it's put together without much design thoughts
   just to address specific need of the hour.
2. It gets obsolete very soon, mainly because of (1)
3. Very platform and vendor specific and soon we will find ourselves
   in ocean of such custom calls

And I can definitely continue the list, but I have made the point.
I think we already have enough of those custom SMC already now and it's
high time to stop that non-sense for OSPM.

--
Regards,
Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Wed, Apr 17, 2019 at 02:30:53PM +0000, Jacky Bai wrote:
>
> Hi Lucas,
>
> Either SCMI or SCPI, I think it is initially designed for SOC that has
> dedicated SCP to manage the SOC resource, but for i.MX8M, we don't have such
> support. so just for the power domain support, do you have other suggestion
> for it.
>

I disagree, I thought it was clear from my earlier email. All OSPM like
Linux kernel cares is conformance to the interface. And SCMI/SCPI kind
of interface doesn't mandate how to implement either at the hardware
(you may or may not have dedicated processor) or software level(can do
it in TF-A through SMC, or some remote process through mailbox)

I am clearly against the custom SMC:

1. It will never end and it's put together without much design thoughts
   just to address specific need of the hour.
2. It gets obsolete very soon, mainly because of (1)
3. Very platform and vendor specific and soon we will find ourselves
   in ocean of such custom calls

And I can definitely continue the list, but I have made the point.
I think we already have enough of those custom SMC already now and it's
high time to stop that non-sense for OSPM.

--
Regards,
Sudeep


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Jacky Bai]

> 
> On Wed, Apr 17, 2019 at 02:30:53PM +0000, Jacky Bai wrote:
> >
> > Hi Lucas,
> >
> > Either SCMI or SCPI, I think it is initially designed for SOC that has
> > dedicated SCP to manage the SOC resource, but for i.MX8M, we don't
> > have such support. so just for the power domain support, do you have
> > other suggestion for it.
> >
> 
> I disagree, I thought it was clear from my earlier email. All OSPM like Linux
> kernel cares is conformance to the interface. And SCMI/SCPI kind of interface
> doesn't mandate how to implement either at the hardware (you may or may
> not have dedicated processor) or software level(can do it in TF-A through SMC,
> or some remote process through mailbox)
> 

For the current SCMI/SCPI driver in mainline kernel, no SCMI/SCPI over SMC support, right?
If we want to make SCMI over SMC as a standard support, does ARM have some suggestion
or plan? :)

> I am clearly against the custom SMC:
> 
> 1. It will never end and it's put together without much design thoughts
>    just to address specific need of the hour.
> 2. It gets obsolete very soon, mainly because of (1) 3. Very platform and
> vendor specific and soon we will find ourselves
>    in ocean of such custom calls
> 
> And I can definitely continue the list, but I have made the point.
> I think we already have enough of those custom SMC already now and it's
> high time to stop that non-sense for OSPM.
> 

>From the ARM SMC calling convention, the SIP service call is designed to
provide SOC specific service, for example, Secure platform initialization,
configuration and some power control. I am confused if upstream kernel will never
accept SIP service patch.

>From the SCMI spec, it provide the clock management for enable/disable/set_rate,
But don't have set_parent support, for i.MX8M platform, we have the requirement to
set clock parent explicitly. If we move to use SCMI framework, how do handle
the set parent?

> --
> Regards,
> Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Peng Fan]

Hi Sudeep,

Sorry if this reply breaks email thread, I need to manual remove some NXP IT policy words from email.

> 
> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> > >>> I don't yet buy the security argument. There are many more shared
> > >>> parts on the SoC, like the clock controller, that would need to be
> > >>> taken away from the non-secure world if one would want to run an
> > >>> untrusted OS kernel on a i.MX8M system.
> > >>>
> > >>> To properly implement security on any i.MX8M based system the
> > >>> firmware would need to grow something like a full ARM SCPI
> > >>> implementation, so all shared critical peripherals are solely under
> firmware control.
> > >>
> > >> It might be possible to rework this to use some form of
> > >> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls
> > >
> > > Sounds feasible and good if all the custom IDs/calls/..etc are well
> > > hidden in the firmware(TF-A in this case) behind the existing
> > > abstraction in Linux kernel.
> >
> > >> Hiding everything critical for security (especially CCM) behind a
> > >> SCMI interface would be a large amount of work but introducing SCMI
> > >> incrementally (starting with imx8mm power) would be useful by
> > >> itself because it simplifies OS implementation.
> > >
> > > Agreed, but not at the expense of introducing and maintaining
> > > *random*
> > > *one-off* *custom* SMC extensions. Sorry, that's not open to debate.
> > >
> > >> Many at NXP have attempted to evaluate SCMI and their conclusion
> > >> has always been that "many extensions are required".
> > >
> > > I would like to hear the evaluation. Don't assume that you need to
> > > implement something similar to ARM SCMI reference design. All OSPM
> > > like Linux kernel cares is conformance to the interface, what/how
> > > you implement on the other side is left to you.
> >
> > Brief summary from some attempts at nudging NXP devs towards SCMI:
> >
> 
> Thanks for providing the evaluation details.
> 
> >
> > There is no SCMI-over-SMC support specified? This would make it
> > possible to use SCMI as a purely software solution on platforms which
> > did not take SCMI into account at hardware design time or which don't
> > have a dedicated SCP inside the SOC. This applies to all imx.
> >
> 
> While I admit, the section of SCMI specification that touches transport is quite
> lean, I would view it as done intentionally as the specification is mainly
> concentrated on it's subject matter which is protocol and not the transport
> itself. So did the evaluation attempted to consider/try SMC as transport
> retaining protocol as is ?
> 
> I can't see any issues with that and hence I am asking it loud here.

To take SMC as a virtual maibox, there is no interrupt doorbell.
So I modify poll_completion to true for my test.

SCMI transports mailbox use a shared memory for data transfer and response.
But actually it should be ok use mailbox registers or smc cpu registers.

> 
> > Peng has been looking at some out-of-tree arm-smc-mailbox patches so
> > it's not just NXP which would like the option of implementing SCMI
> > vendor side in ATF. Like this:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.
> >
> net%2FArticles%2F726861%2F&data=02%7C01%7Cpeng.fan%40nxp.co
> m%7Cc6b
> >
> 07ec02c5d4fa6c24908d6c40c3dcf%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7
> >
> C0%7C636911954210639761&sdata=pJ8bHojmm8bP4sft2cBxzocdN%2F
> bLFQdGeW
> > 2ilnnfzw8%3D&reserved=0
> >
> 
> OK, any inputs from that study ?

I am still at a very initial stage trying scmi over smc with basic communication work,
Base protocol, power domain protocol work. Power domain set/get still not ready.

As Leonard mentioned before, clk hierarchy is very intricate and it relies on many
clk core features. We need SCMI spec could cover that, such as mux, parent.

I have not tried clock protocol, if wrong, please correct
1. CLOCK_RATE_SET/RATE_GET will hide the complexity for OS, but move the 
  complexity to firmware. 
  However, on i.MX8M, we would keep the clk hierarchy in Linux side, and
  in firmware we add a check to check whether allow the mux, reparent, 
  gate change or not. In this way, we could minimize the firmware binary
  size and use Linux clk core features. clk-scmi.c are not able to serve the
  requirement, we need do clk_register with mux/gate/divider with SCMI
  wrapper in Linux side.
2. Some i.MX8M power domain on needs clk being enabled, such as
  https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/arm64/boot/dts/freescale/imx8mq.dtsi#L320
  need extend scmi driver. However scmi does not have a power domain
  tree in Linux dts, it call into firmware to find which power domain is needed
  for Linux, then register it.

3. some i.MX8M power domain off needs external regulator power off
  to save power, need extend scmi driver. But since there is no power domain
  tree, I do not find a good way to add regulator. Moving regulator logic
  to firmware will require i2c support in ATF to communicate with pmic,
  however pmic has many outputs not only for the upper power domain,
  moving i2c to ATF will incur risk when OS and ATF both access the pmic.

> 
> > Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI
> > message in EL2; checking if the guest is allowed to use that resource
> > and then either forward to EL3 or return an error.
> >
> 
> Why are you mixing virtualisation and EL2 here ? Yes we need them but it
> should be optional and if a platform doesn't need it, it should be possible to
> skip it.
> 
> >
> > SCMI clock protocol does not cover muxes? On imx the clk hierarchy is
> > very intricate and it relies on many clk core features (including
> > notifiers) and occasional assigned-clocks-parents properties to
> > control muxes from linux. Moving all that to firmware would be a huge
> > amount of effort.
> >
> 
> Yes it may be huge amount of work. But is it completely safe as claimed ?
> Giving access to mux controls in OSPM is no so safe/secure in the modern
> world. So you either make it safe with that extra huge effort needed or just
> keep everything in OSPM. But IMO anything in between is not worth it.
> 
> > If SCMI included a generic clk mux and allowed keeping the clk
> > hierarchy inside linux then the effort required for hiding the CCM
> > would still be large, but more approachable. It would not "simplify
> > the rich OS" but it would still improve security.
> >
> 
> Why do you need to keep the clk hierarchy in Linux ?

Just replied above.

Hiding the clk tree in Linux would keep the complexity
in ATF in our case, and enlarge the ATF binary size, and not
able to use some clk core features.

> 
> >
> > Last point is that SCMI does not cover pinctrl? This is a large chunk
> > of firmware functionality on some imx and security control over
> > individual pins is desirable.
> >
> 
> Yes but is that something available at runtime ? Can't that be one-off firmware
> setting. Will Linux need to configure it differently on each boot ?
> Just trying to understand. You say security control here and is it really safe to
> give OS access to control those ?

There is a iomux controller for pinctrl usage on i.MX8M, it could be set to
secure world read/write, Non secure world read/write block.
With pinctrl over SCMI, we could add check to see whether allow Linux
to modify some iomux registers that are used by TEE.

> 
> In short, if you had a full blown protocol like few other platforms, the push
> back would have been minimal. Instead, i.MX chose to implement a solution
> which doesn't have a design thought before and custom SMC APIs added on
> fly whenever a new request is raised by OSPM to control things that it thinks it
> should. I am sure, the very next platform will have it's own set of
> requirements and custom SMC APIs/interface and no one has even bothered
> about long term maintenance of these.
> 

As I tried and still trying SCMI over SMC, the current SCMI spec/code
could not serve our requirement.

I wonder will SCMI spec open to community and maintained by
community for adding new feature? If there is github repo for this,
I think we could submit issue/pull request for new feature.
Or is it possible that we submit code to Linux scmi, then drive SCMI
spec change?

Thanks,
Peng.

> So assuming that trend, I would NACK this as it stands.
> 
> --
> Regards,
> Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Sat, Apr 20, 2019 at 01:38:14PM +0000, Peng Fan wrote:
> Hi Sudeep,
>
> Sorry if this reply breaks email thread, I need to manual remove some NXP IT
> policy words from email.
>

Ah OK, indeed threading is lost, had to manually search as I had marked
it to reply later.

> >
> > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:

[...]

> >
> > While I admit, the section of SCMI specification that touches transport is quite
> > lean, I would view it as done intentionally as the specification is mainly
> > concentrated on it's subject matter which is protocol and not the transport
> > itself. So did the evaluation attempted to consider/try SMC as transport
> > retaining protocol as is ?
> >
> > I can't see any issues with that and hence I am asking it loud here.
>
> To take SMC as a virtual maibox, there is no interrupt doorbell.
> So I modify poll_completion to true for my test.
>

OK fair enough, but that's something we should be easily able to fix.

> SCMI transports mailbox use a shared memory for data transfer and response.
> But actually it should be ok use mailbox registers or smc cpu registers.
>

Indeed.


[...]

> > OK, any inputs from that study ?
>
> I am still at a very initial stage trying scmi over smc with basic communication work,
> Base protocol, power domain protocol work. Power domain set/get still not ready.
>

Good to know, there are efforts in that direction. Thanks for that.

> As Leonard mentioned before, clk hierarchy is very intricate and it relies on many
> clk core features. We need SCMI spec could cover that, such as mux, parent.
>
> I have not tried clock protocol, if wrong, please correct
> 1. CLOCK_RATE_SET/RATE_GET will hide the complexity for OS, but move the
>   complexity to firmware.
>   However, on i.MX8M, we would keep the clk hierarchy in Linux side, and
>   in firmware we add a check to check whether allow the mux, reparent,
>   gate change or not. In this way, we could minimize the firmware binary
>   size and use Linux clk core features. clk-scmi.c are not able to serve the
>   requirement, we need do clk_register with mux/gate/divider with SCMI
>   wrapper in Linux side.

Agreed, but we wanted to avoid complexity as it's very platform specific
and can't be easily generalized. While moving this to firmware might
make it complex, but that's very platform specific.

> 2. Some i.MX8M power domain on needs clk being enabled, such as
>   https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/arm64/boot/dts/freescale/imx8mq.dtsi#L320
>   need extend scmi driver. However scmi does not have a power domain
>   tree in Linux dts, it call into firmware to find which power domain is needed
>   for Linux, then register it.
>

Not sure about this, unable to follow what you mean by that ?


> 3. some i.MX8M power domain off needs external regulator power off
>   to save power, need extend scmi driver. But since there is no power domain
>   tree, I do not find a good way to add regulator. Moving regulator logic
>   to firmware will require i2c support in ATF to communicate with pmic,
>   however pmic has many outputs not only for the upper power domain,
>   moving i2c to ATF will incur risk when OS and ATF both access the pmic.
>

Yes regulators are removed(rather never added) for good from SCMI
specification. You just need good reasons to have them. Linux must
learn to deal with absence of it if it doesn't already.

[...]

> >
> > Why do you need to keep the clk hierarchy in Linux ?
>
> Just replied above.
>
> Hiding the clk tree in Linux would keep the complexity
> in ATF in our case, and enlarge the ATF binary size, and not
> able to use some clk core features.
>

Agreed on firmware complexity, but as I mentioned it's too platform
specific and hard to generalize. We can see what can be added to extend
existing clock support in SCMI if required.

> > >
> > > Last point is that SCMI does not cover pinctrl? This is a large chunk
> > > of firmware functionality on some imx and security control over
> > > individual pins is desirable.
> > >
> >
> > Yes but is that something available at runtime ? Can't that be one-off firmware
> > setting. Will Linux need to configure it differently on each boot ?
> > Just trying to understand. You say security control here and is it really safe to
> > give OS access to control those ?
>
> There is a iomux controller for pinctrl usage on i.MX8M, it could be set to
> secure world read/write, Non secure world read/write block.
> With pinctrl over SCMI, we could add check to see whether allow Linux
> to modify some iomux registers that are used by TEE.
>

OK, something to look at in detail if we need this in the specification.

> >
> > In short, if you had a full blown protocol like few other platforms, the push
> > back would have been minimal. Instead, i.MX chose to implement a solution
> > which doesn't have a design thought before and custom SMC APIs added on
> > fly whenever a new request is raised by OSPM to control things that it thinks it
> > should. I am sure, the very next platform will have it's own set of
> > requirements and custom SMC APIs/interface and no one has even bothered
> > about long term maintenance of these.
> >
>
> As I tried and still trying SCMI over SMC, the current SCMI spec/code
> could not serve our requirement.
>
> I wonder will SCMI spec open to community and maintained by
> community for adding new feature? If there is github repo for this,
> I think we could submit issue/pull request for new feature.
> Or is it possible that we submit code to Linux scmi, then drive SCMI
> spec change?
>

I would rather first add the new features to the specification before
adding the code. SCMI was sent to all ARM vendors for review(I am sure
NXP was also part of it), though as usual it will be ignored until it
will be enforced to be looked at and reviewed. So feel free to send me
details the SCMI enhancements you would need.

--
Regards,
Sudeep

Re: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Sudeep Holla]

On Sat, Apr 20, 2019 at 01:38:14PM +0000, Peng Fan wrote:
> Hi Sudeep,
>
> Sorry if this reply breaks email thread, I need to manual remove some NXP IT
> policy words from email.
>

Ah OK, indeed threading is lost, had to manually search as I had marked
it to reply later.

> >
> > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:

[...]

> >
> > While I admit, the section of SCMI specification that touches transport is quite
> > lean, I would view it as done intentionally as the specification is mainly
> > concentrated on it's subject matter which is protocol and not the transport
> > itself. So did the evaluation attempted to consider/try SMC as transport
> > retaining protocol as is ?
> >
> > I can't see any issues with that and hence I am asking it loud here.
>
> To take SMC as a virtual maibox, there is no interrupt doorbell.
> So I modify poll_completion to true for my test.
>

OK fair enough, but that's something we should be easily able to fix.

> SCMI transports mailbox use a shared memory for data transfer and response.
> But actually it should be ok use mailbox registers or smc cpu registers.
>

Indeed.


[...]

> > OK, any inputs from that study ?
>
> I am still at a very initial stage trying scmi over smc with basic communication work,
> Base protocol, power domain protocol work. Power domain set/get still not ready.
>

Good to know, there are efforts in that direction. Thanks for that.

> As Leonard mentioned before, clk hierarchy is very intricate and it relies on many
> clk core features. We need SCMI spec could cover that, such as mux, parent.
>
> I have not tried clock protocol, if wrong, please correct
> 1. CLOCK_RATE_SET/RATE_GET will hide the complexity for OS, but move the
>   complexity to firmware.
>   However, on i.MX8M, we would keep the clk hierarchy in Linux side, and
>   in firmware we add a check to check whether allow the mux, reparent,
>   gate change or not. In this way, we could minimize the firmware binary
>   size and use Linux clk core features. clk-scmi.c are not able to serve the
>   requirement, we need do clk_register with mux/gate/divider with SCMI
>   wrapper in Linux side.

Agreed, but we wanted to avoid complexity as it's very platform specific
and can't be easily generalized. While moving this to firmware might
make it complex, but that's very platform specific.

> 2. Some i.MX8M power domain on needs clk being enabled, such as
>   https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/arm64/boot/dts/freescale/imx8mq.dtsi#L320
>   need extend scmi driver. However scmi does not have a power domain
>   tree in Linux dts, it call into firmware to find which power domain is needed
>   for Linux, then register it.
>

Not sure about this, unable to follow what you mean by that ?


> 3. some i.MX8M power domain off needs external regulator power off
>   to save power, need extend scmi driver. But since there is no power domain
>   tree, I do not find a good way to add regulator. Moving regulator logic
>   to firmware will require i2c support in ATF to communicate with pmic,
>   however pmic has many outputs not only for the upper power domain,
>   moving i2c to ATF will incur risk when OS and ATF both access the pmic.
>

Yes regulators are removed(rather never added) for good from SCMI
specification. You just need good reasons to have them. Linux must
learn to deal with absence of it if it doesn't already.

[...]

> >
> > Why do you need to keep the clk hierarchy in Linux ?
>
> Just replied above.
>
> Hiding the clk tree in Linux would keep the complexity
> in ATF in our case, and enlarge the ATF binary size, and not
> able to use some clk core features.
>

Agreed on firmware complexity, but as I mentioned it's too platform
specific and hard to generalize. We can see what can be added to extend
existing clock support in SCMI if required.

> > >
> > > Last point is that SCMI does not cover pinctrl? This is a large chunk
> > > of firmware functionality on some imx and security control over
> > > individual pins is desirable.
> > >
> >
> > Yes but is that something available at runtime ? Can't that be one-off firmware
> > setting. Will Linux need to configure it differently on each boot ?
> > Just trying to understand. You say security control here and is it really safe to
> > give OS access to control those ?
>
> There is a iomux controller for pinctrl usage on i.MX8M, it could be set to
> secure world read/write, Non secure world read/write block.
> With pinctrl over SCMI, we could add check to see whether allow Linux
> to modify some iomux registers that are used by TEE.
>

OK, something to look at in detail if we need this in the specification.

> >
> > In short, if you had a full blown protocol like few other platforms, the push
> > back would have been minimal. Instead, i.MX chose to implement a solution
> > which doesn't have a design thought before and custom SMC APIs added on
> > fly whenever a new request is raised by OSPM to control things that it thinks it
> > should. I am sure, the very next platform will have it's own set of
> > requirements and custom SMC APIs/interface and no one has even bothered
> > about long term maintenance of these.
> >
>
> As I tried and still trying SCMI over SMC, the current SCMI spec/code
> could not serve our requirement.
>
> I wonder will SCMI spec open to community and maintained by
> community for adding new feature? If there is github repo for this,
> I think we could submit issue/pull request for new feature.
> Or is it possible that we submit code to Linux scmi, then drive SCMI
> spec change?
>

I would rather first add the new features to the specification before
adding the code. SCMI was sent to all ARM vendors for review(I am sure
NXP was also part of it), though as usual it will be ignored until it
will be enforced to be looked at and reviewed. So feel free to send me
details the SCMI enhancements you would need.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Peng Fan]

Hi Sudeep,

> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> On Sat, Apr 20, 2019 at 01:38:14PM +0000, Peng Fan wrote:
> > Hi Sudeep,
> >
> > Sorry if this reply breaks email thread, I need to manual remove some
> > NXP IT policy words from email.
> >
> 
> Ah OK, indeed threading is lost, had to manually search as I had marked it to
> reply later.
> 
> > >
> > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> 
> [...]
> 
> > >
> > > While I admit, the section of SCMI specification that touches
> > > transport is quite lean, I would view it as done intentionally as
> > > the specification is mainly concentrated on it's subject matter
> > > which is protocol and not the transport itself. So did the
> > > evaluation attempted to consider/try SMC as transport retaining protocol
> as is ?
> > >
> > > I can't see any issues with that and hence I am asking it loud here.
> >
> > To take SMC as a virtual maibox, there is no interrupt doorbell.
> > So I modify poll_completion to true for my test.
> >
> 
> OK fair enough, but that's something we should be easily able to fix.
> 
> > SCMI transports mailbox use a shared memory for data transfer and
> response.
> > But actually it should be ok use mailbox registers or smc cpu registers.
> >
> 
> Indeed.
> 
> 
> [...]
> 
> > > OK, any inputs from that study ?
> >
> > I am still at a very initial stage trying scmi over smc with basic
> > communication work, Base protocol, power domain protocol work. Power
> domain set/get still not ready.
> >
> 
> Good to know, there are efforts in that direction. Thanks for that.
> 
> > As Leonard mentioned before, clk hierarchy is very intricate and it
> > relies on many clk core features. We need SCMI spec could cover that, such
> as mux, parent.
> >
> > I have not tried clock protocol, if wrong, please correct 1.
> > CLOCK_RATE_SET/RATE_GET will hide the complexity for OS, but move the
> >   complexity to firmware.
> >   However, on i.MX8M, we would keep the clk hierarchy in Linux side, and
> >   in firmware we add a check to check whether allow the mux, reparent,
> >   gate change or not. In this way, we could minimize the firmware binary
> >   size and use Linux clk core features. clk-scmi.c are not able to serve the
> >   requirement, we need do clk_register with mux/gate/divider with SCMI
> >   wrapper in Linux side.
> 
> Agreed, but we wanted to avoid complexity as it's very platform specific and
> can't be easily generalized. While moving this to firmware might make it
> complex, but that's very platform specific.
> 
> > 2. Some i.MX8M power domain on needs clk being enabled, such as
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> ootlin.com%2Flinux%2Fv5.1-rc5%2Fsource%2Farch%2Farm64%2Fboot%2Fdt
> s%2Ffreescale%2Fimx8mq.dtsi%23L320&data=02%7C01%7Cpeng.fan%4
> 0nxp.com%7Cd7c896c5acfe429872c308d6c7dbdae3%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C636916144468358717&sdata=jLlV2D
> UstQyedH7lg182PFXywlFn8708TKy5PZVLxtc%3D&reserved=0
> >   need extend scmi driver. However scmi does not have a power domain
> >   tree in Linux dts, it call into firmware to find which power domain is
> needed
> >   for Linux, then register it.
> >
> 
> Not sure about this, unable to follow what you mean by that ?

The code in vendor tree is here:
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/soc/imx/gpc-psci.c?h=imx_4.14.98_2.0.0_ga#n216

When power on a power domain for some IP block, the clks
needs to be enabled first.

So with SCMI, we could not only start with power domain because
of some IP requires clks enabled first and SCMI power domain driver
not support that function.

So we have to considering clk over SCMI at the very first and develop
a framework that could work well in ATF to serve OS. And because
the i.MX8MM clk driver already merged to upstream, that means that piece
code needs to be dropped if use SCMI clk.
But I did not see any attempt from other SoC vendors to moving the clk
details into ATF, I am not very sure it is the right approach.

I am also not sure other i.MX stakeholder's opinions. Lucas, Shawn, Aisheng,

What do you suggest?


> 
> 
> > 3. some i.MX8M power domain off needs external regulator power off
> >   to save power, need extend scmi driver. But since there is no power
> domain
> >   tree, I do not find a good way to add regulator. Moving regulator logic
> >   to firmware will require i2c support in ATF to communicate with pmic,
> >   however pmic has many outputs not only for the upper power domain,
> >   moving i2c to ATF will incur risk when OS and ATF both access the pmic.
> >
> 
> Yes regulators are removed(rather never added) for good from SCMI
> specification. You just need good reasons to have them. Linux must learn to
> deal with absence of it if it doesn't already.
> 
> [...]
> 
> > >
> > > Why do you need to keep the clk hierarchy in Linux ?
> >
> > Just replied above.
> >
> > Hiding the clk tree in Linux would keep the complexity in ATF in our
> > case, and enlarge the ATF binary size, and not able to use some clk
> > core features.
> >
> 
> Agreed on firmware complexity, but as I mentioned it's too platform specific
> and hard to generalize. We can see what can be added to extend existing
> clock support in SCMI if required.
> 
> > > >
> > > > Last point is that SCMI does not cover pinctrl? This is a large
> > > > chunk of firmware functionality on some imx and security control
> > > > over individual pins is desirable.
> > > >
> > >
> > > Yes but is that something available at runtime ? Can't that be
> > > one-off firmware setting. Will Linux need to configure it differently on
> each boot ?
> > > Just trying to understand. You say security control here and is it
> > > really safe to give OS access to control those ?
> >
> > There is a iomux controller for pinctrl usage on i.MX8M, it could be
> > set to secure world read/write, Non secure world read/write block.
> > With pinctrl over SCMI, we could add check to see whether allow Linux
> > to modify some iomux registers that are used by TEE.
> >
> 
> OK, something to look at in detail if we need this in the specification.
> 
> > >
> > > In short, if you had a full blown protocol like few other platforms,
> > > the push back would have been minimal. Instead, i.MX chose to
> > > implement a solution which doesn't have a design thought before and
> > > custom SMC APIs added on fly whenever a new request is raised by
> > > OSPM to control things that it thinks it should. I am sure, the very
> > > next platform will have it's own set of requirements and custom SMC
> > > APIs/interface and no one has even bothered about long term
> maintenance of these.
> > >
> >
> > As I tried and still trying SCMI over SMC, the current SCMI spec/code
> > could not serve our requirement.
> >
> > I wonder will SCMI spec open to community and maintained by community
> > for adding new feature? If there is github repo for this, I think we
> > could submit issue/pull request for new feature.
> > Or is it possible that we submit code to Linux scmi, then drive SCMI
> > spec change?
> >
> 
> I would rather first add the new features to the specification before adding the
> code. SCMI was sent to all ARM vendors for review(I am sure NXP was also
> part of it), though as usual it will be ignored until it will be enforced to be
> looked at and reviewed. So feel free to send me details the SCMI
> enhancements you would need.

Not sure i.MX maintainer's opinion, and inside NXP we still need to discuss
the final approach. If settle down to choose SCMI over SMC, we will
send you details.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep

RE: [PATCH 0/3] Add power domain driver support for i.mx8m family

[Peng Fan]

Hi Sudeep,

> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family
> 
> On Sat, Apr 20, 2019 at 01:38:14PM +0000, Peng Fan wrote:
> > Hi Sudeep,
> >
> > Sorry if this reply breaks email thread, I need to manual remove some
> > NXP IT policy words from email.
> >
> 
> Ah OK, indeed threading is lost, had to manually search as I had marked it to
> reply later.
> 
> > >
> > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote:
> > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote:
> 
> [...]
> 
> > >
> > > While I admit, the section of SCMI specification that touches
> > > transport is quite lean, I would view it as done intentionally as
> > > the specification is mainly concentrated on it's subject matter
> > > which is protocol and not the transport itself. So did the
> > > evaluation attempted to consider/try SMC as transport retaining protocol
> as is ?
> > >
> > > I can't see any issues with that and hence I am asking it loud here.
> >
> > To take SMC as a virtual maibox, there is no interrupt doorbell.
> > So I modify poll_completion to true for my test.
> >
> 
> OK fair enough, but that's something we should be easily able to fix.
> 
> > SCMI transports mailbox use a shared memory for data transfer and
> response.
> > But actually it should be ok use mailbox registers or smc cpu registers.
> >
> 
> Indeed.
> 
> 
> [...]
> 
> > > OK, any inputs from that study ?
> >
> > I am still at a very initial stage trying scmi over smc with basic
> > communication work, Base protocol, power domain protocol work. Power
> domain set/get still not ready.
> >
> 
> Good to know, there are efforts in that direction. Thanks for that.
> 
> > As Leonard mentioned before, clk hierarchy is very intricate and it
> > relies on many clk core features. We need SCMI spec could cover that, such
> as mux, parent.
> >
> > I have not tried clock protocol, if wrong, please correct 1.
> > CLOCK_RATE_SET/RATE_GET will hide the complexity for OS, but move the
> >   complexity to firmware.
> >   However, on i.MX8M, we would keep the clk hierarchy in Linux side, and
> >   in firmware we add a check to check whether allow the mux, reparent,
> >   gate change or not. In this way, we could minimize the firmware binary
> >   size and use Linux clk core features. clk-scmi.c are not able to serve the
> >   requirement, we need do clk_register with mux/gate/divider with SCMI
> >   wrapper in Linux side.
> 
> Agreed, but we wanted to avoid complexity as it's very platform specific and
> can't be easily generalized. While moving this to firmware might make it
> complex, but that's very platform specific.
> 
> > 2. Some i.MX8M power domain on needs clk being enabled, such as
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> ootlin.com%2Flinux%2Fv5.1-rc5%2Fsource%2Farch%2Farm64%2Fboot%2Fdt
> s%2Ffreescale%2Fimx8mq.dtsi%23L320&data=02%7C01%7Cpeng.fan%4
> 0nxp.com%7Cd7c896c5acfe429872c308d6c7dbdae3%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C636916144468358717&sdata=jLlV2D
> UstQyedH7lg182PFXywlFn8708TKy5PZVLxtc%3D&reserved=0
> >   need extend scmi driver. However scmi does not have a power domain
> >   tree in Linux dts, it call into firmware to find which power domain is
> needed
> >   for Linux, then register it.
> >
> 
> Not sure about this, unable to follow what you mean by that ?

The code in vendor tree is here:
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/soc/imx/gpc-psci.c?h=imx_4.14.98_2.0.0_ga#n216

When power on a power domain for some IP block, the clks
needs to be enabled first.

So with SCMI, we could not only start with power domain because
of some IP requires clks enabled first and SCMI power domain driver
not support that function.

So we have to considering clk over SCMI at the very first and develop
a framework that could work well in ATF to serve OS. And because
the i.MX8MM clk driver already merged to upstream, that means that piece
code needs to be dropped if use SCMI clk.
But I did not see any attempt from other SoC vendors to moving the clk
details into ATF, I am not very sure it is the right approach.

I am also not sure other i.MX stakeholder's opinions. Lucas, Shawn, Aisheng,

What do you suggest?


> 
> 
> > 3. some i.MX8M power domain off needs external regulator power off
> >   to save power, need extend scmi driver. But since there is no power
> domain
> >   tree, I do not find a good way to add regulator. Moving regulator logic
> >   to firmware will require i2c support in ATF to communicate with pmic,
> >   however pmic has many outputs not only for the upper power domain,
> >   moving i2c to ATF will incur risk when OS and ATF both access the pmic.
> >
> 
> Yes regulators are removed(rather never added) for good from SCMI
> specification. You just need good reasons to have them. Linux must learn to
> deal with absence of it if it doesn't already.
> 
> [...]
> 
> > >
> > > Why do you need to keep the clk hierarchy in Linux ?
> >
> > Just replied above.
> >
> > Hiding the clk tree in Linux would keep the complexity in ATF in our
> > case, and enlarge the ATF binary size, and not able to use some clk
> > core features.
> >
> 
> Agreed on firmware complexity, but as I mentioned it's too platform specific
> and hard to generalize. We can see what can be added to extend existing
> clock support in SCMI if required.
> 
> > > >
> > > > Last point is that SCMI does not cover pinctrl? This is a large
> > > > chunk of firmware functionality on some imx and security control
> > > > over individual pins is desirable.
> > > >
> > >
> > > Yes but is that something available at runtime ? Can't that be
> > > one-off firmware setting. Will Linux need to configure it differently on
> each boot ?
> > > Just trying to understand. You say security control here and is it
> > > really safe to give OS access to control those ?
> >
> > There is a iomux controller for pinctrl usage on i.MX8M, it could be
> > set to secure world read/write, Non secure world read/write block.
> > With pinctrl over SCMI, we could add check to see whether allow Linux
> > to modify some iomux registers that are used by TEE.
> >
> 
> OK, something to look at in detail if we need this in the specification.
> 
> > >
> > > In short, if you had a full blown protocol like few other platforms,
> > > the push back would have been minimal. Instead, i.MX chose to
> > > implement a solution which doesn't have a design thought before and
> > > custom SMC APIs added on fly whenever a new request is raised by
> > > OSPM to control things that it thinks it should. I am sure, the very
> > > next platform will have it's own set of requirements and custom SMC
> > > APIs/interface and no one has even bothered about long term
> maintenance of these.
> > >
> >
> > As I tried and still trying SCMI over SMC, the current SCMI spec/code
> > could not serve our requirement.
> >
> > I wonder will SCMI spec open to community and maintained by community
> > for adding new feature? If there is github repo for this, I think we
> > could submit issue/pull request for new feature.
> > Or is it possible that we submit code to Linux scmi, then drive SCMI
> > spec change?
> >
> 
> I would rather first add the new features to the specification before adding the
> code. SCMI was sent to all ARM vendors for review(I am sure NXP was also
> part of it), though as usual it will be ignored until it will be enforced to be
> looked at and reviewed. So feel free to send me details the SCMI
> enhancements you would need.

Not sure i.MX maintainer's opinion, and inside NXP we still need to discuss
the final approach. If settle down to choose SCMI over SMC, we will
send you details.

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel