* [PATCH 7/7] arm64: dts: imx8mm: Add devfreq nodes
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Add initial support for bus scaling on imx8m, starting with noc and ddrc
because they're the biggest power hogs.
Add a devfreq-event link to the PMU in order to support on-demand
scaling of ddrc based on measured dram bandwith usage. Make ddrc a
parent of the NOC because all traffic to ddrc goes through
Support for proactive scaling via interconnect and support for scaling
additional NICs will come later. The high-performance bus masters which
need that (display, vpu, gpu) are not yet enabled in upstream anyway.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 51 ++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index e8560d15c130..a37d82133c06 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -122,10 +122,38 @@
clock-latency-ns = <150000>;
opp-suspend;
};
};
+ ddrc_opp_table: ddrc-opp-table {
+ compatible = "operating-points-v2";
+
+ opp-25M {
+ opp-hz = /bits/ 64 <25000000>;
+ };
+ opp-100M {
+ opp-hz = /bits/ 64 <100000000>;
+ };
+ opp-750M {
+ opp-hz = /bits/ 64 <750000000>;
+ };
+ };
+
+ noc_opp_table: noc-opp-table {
+ compatible = "operating-points-v2";
+
+ opp-150M {
+ opp-hz = /bits/ 64 <150000000>;
+ };
+ opp-375M {
+ opp-hz = /bits/ 64 <375000000>;
+ };
+ opp-750M {
+ opp-hz = /bits/ 64 <750000000>;
+ };
+ };
+
memory@40000000 {
device_type = "memory";
reg = <0x0 0x40000000 0 0x80000000>;
};
@@ -748,10 +776,18 @@
status = "disabled";
};
};
+ noc: noc@32700000 {
+ compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc";
+ reg = <0x32700000 0x100000>;
+ clocks = <&clk IMX8MM_CLK_NOC>;
+ devfreq = <&ddrc>;
+ operating-points-v2 = <&noc_opp_table>;
+ };
+
aips4: bus@32c00000 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x32c00000 0x32c00000 0x400000>;
@@ -832,11 +868,24 @@
#interrupt-cells = <3>;
interrupt-controller;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
- ddr-pmu@3d800000 {
+ ddrc: dram-controller@3d400000 {
+ compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc";
+ reg = <0x3d400000 0x400000>;
+ clock-names = "dram_core", "dram_pll", "dram_alt_root", "dram_alt", "dram_apb";
+ clocks = <&clk IMX8MM_CLK_DRAM_CORE>,
+ <&clk IMX8MM_DRAM_PLL>,
+ <&clk IMX8MM_CLK_DRAM_ALT_ROOT>,
+ <&clk IMX8MM_CLK_DRAM_ALT>,
+ <&clk IMX8MM_CLK_DRAM_APB>;
+ devfreq-events = <&ddr_pmu>;
+ operating-points-v2 = <&ddrc_opp_table>;
+ };
+
+ ddr_pmu: ddr-pmu@3d800000 {
compatible = "fsl,imx8mm-ddr-pmu", "fsl,imx8m-ddr-pmu";
reg = <0x3d800000 0x400000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/7] PM / devfreq: Add dynamic scaling for imx ddr controller
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Add driver for dynamic scaling the DDR Controller on imx8m chips. Actual
frequency switching is implemented in TF-A, this driver just wraps the
SMC calls and updates the clk tree.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/devfreq/Makefile | 2 +-
drivers/devfreq/imx-ddrc.c | 379 +++++++++++++++++++++++++++++++++++++
2 files changed, 380 insertions(+), 1 deletion(-)
create mode 100644 drivers/devfreq/imx-ddrc.c
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index c2463ed4c934..eba138914c74 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -7,11 +7,11 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
-obj-$(CONFIG_ARM_IMX_DEVFREQ) += imx-devfreq.o
+obj-$(CONFIG_ARM_IMX_DEVFREQ) += imx-devfreq.o imx-ddrc.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o
obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o
# DEVFREQ Event Drivers
diff --git a/drivers/devfreq/imx-ddrc.c b/drivers/devfreq/imx-ddrc.c
new file mode 100644
index 000000000000..e46a1e711bc6
--- /dev/null
+++ b/drivers/devfreq/imx-ddrc.c
@@ -0,0 +1,379 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 NXP
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/devfreq.h>
+#include <linux/pm_opp.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/arm-smccc.h>
+
+#define IMX_SIP_DDR_DVFS 0xc2000004
+
+/* Values starting from 0 switch to specific frequency */
+#define IMX_SIP_DDR_FREQ_SET_HIGH 0x00
+
+/* Deprecated after moving IRQ handling to ATF */
+#define IMX_SIP_DDR_DVFS_WAIT_CHANGE 0x0F
+
+/* Query available frequencies. */
+#define IMX_SIP_DDR_DVFS_GET_FREQ_COUNT 0x10
+#define IMX_SIP_DDR_DVFS_GET_FREQ_INFO 0x11
+
+/*
+ * This should be in a 1:1 mapping with devicetree OPPs but
+ * firmware provides additional info.
+ */
+struct imx_ddrc_freq {
+ unsigned long rate;
+ unsigned long smcarg;
+ int dram_core_parent_index;
+ int dram_alt_parent_index;
+ int dram_apb_parent_index;
+};
+
+/* Hardware limitation */
+#define IMX_DDRC_MAX_FREQ_COUNT 4
+
+/*
+ * imx DRAM controller
+ *
+ * imx DRAM controller clocks have the following structure (abridged):
+ *
+ * +----------+ |\ +------+
+ * | dram_pll |-------|M| dram_core | |
+ * +----------+ |U|---------->| D |
+ * /--|X| | D |
+ * dram_alt_root | |/ | R |
+ * | | C |
+ * +---------+ | |
+ * |FIX DIV/4| | |
+ * +---------+ | |
+ * composite: | | |
+ * +----------+ | | |
+ * | dram_alt |----/ | |
+ * +----------+ | |
+ * | dram_apb |-------------------->| |
+ * +----------+ +------+
+ *
+ * The dram_pll is used for higher rates and dram_alt is used for lower rates.
+ *
+ * Frequency switching is implemented in TF-A (via SMC call) and can change the
+ * configuration of the clocks, including mux parents. The dram_alt and
+ * dram_apb clocks are "imx composite" and their parent can change too.
+ *
+ * We need to prepare/enable the new mux parents head of switching and update
+ * their information afterwards.
+ */
+struct imx_ddrc {
+ struct devfreq_dev_profile profile;
+ struct devfreq *devfreq;
+
+ /* For frequency switching: */
+ struct clk *dram_core;
+ struct clk *dram_pll;
+ struct clk *dram_alt_root;
+ struct clk *dram_alt;
+ struct clk *dram_apb;
+
+ int freq_count;
+ struct imx_ddrc_freq freq_table[IMX_DDRC_MAX_FREQ_COUNT];
+};
+
+static struct imx_ddrc_freq* imx_ddrc_find_freq(struct imx_ddrc* priv,
+ unsigned long rate)
+{
+ int i;
+
+ for (i = 0; i < priv->freq_count; ++i)
+ if (priv->freq_table[i].rate == rate)
+ return &priv->freq_table[i];
+
+ return NULL;
+}
+
+static void imx_ddrc_smc_set_freq(int target_freq)
+{
+ struct arm_smccc_res res;
+ u32 online_cpus = 0;
+ int cpu;
+
+ local_irq_disable();
+
+ for_each_online_cpu(cpu)
+ online_cpus |= (1 << (cpu * 8));
+
+ /* change the ddr freqency */
+ arm_smccc_smc(IMX_SIP_DDR_DVFS, target_freq, online_cpus,
+ 0, 0, 0, 0, 0, &res);
+
+ local_irq_enable();
+}
+
+struct clk *clk_get_parent_by_index(struct clk* clk, int index)
+{
+ struct clk_hw *hw;
+
+ hw = clk_hw_get_parent_by_index(__clk_get_hw(clk), index);
+
+ return hw ? hw->clk : NULL;
+}
+
+static int imx_ddrc_set_freq(struct device *dev, struct imx_ddrc_freq* freq)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+ struct clk* new_dram_core_parent;
+ struct clk* new_dram_alt_parent;
+ struct clk* new_dram_apb_parent;
+ int ret;
+
+ new_dram_core_parent = clk_get_parent_by_index(
+ priv->dram_core, freq->dram_core_parent_index - 1);
+ new_dram_alt_parent = clk_get_parent_by_index(
+ priv->dram_alt, freq->dram_alt_parent_index - 1);
+ new_dram_apb_parent = clk_get_parent_by_index(
+ priv->dram_apb, freq->dram_apb_parent_index - 1);
+
+ /* increase reference counts and ensure clks are ON before switch */
+ ret = clk_prepare_enable(new_dram_core_parent);
+ if (ret) {
+ dev_err(dev, "failed enable new dram_core parent: %d\n", ret);
+ goto out;
+ }
+ ret = clk_prepare_enable(new_dram_alt_parent);
+ if (ret) {
+ dev_err(dev, "failed enable new dram_alt parent: %d\n", ret);
+ goto out_dis_core;
+ }
+ ret = clk_prepare_enable(new_dram_apb_parent);
+ if (ret) {
+ dev_err(dev, "failed enable new dram_apb parent: %d\n", ret);
+ goto out_dis_alt;
+ }
+
+ imx_ddrc_smc_set_freq(freq->smcarg);
+
+ /* update parents in clk tree after switch. */
+ ret = clk_set_parent(priv->dram_core, new_dram_core_parent);
+ if (ret)
+ dev_err(dev, "failed clk_set_parent dram_core: %d\n", ret);
+ if (new_dram_alt_parent) {
+ ret = clk_set_parent(priv->dram_alt, new_dram_alt_parent);
+ if (ret)
+ dev_err(dev, "failed clk_set_parent dram_alt_parent: %d\n", ret);
+ }
+ if (new_dram_apb_parent) {
+ ret = clk_set_parent(priv->dram_apb, new_dram_apb_parent);
+ if (ret)
+ dev_err(dev, "failed clk_set_parent dram_apb_parent: %d\n", ret);
+ }
+
+ /*
+ * clk_set_parent transfer the reference count from old parent.
+ * now we drop extra reference counts used during the switch
+ */
+ clk_disable_unprepare(new_dram_apb_parent);
+out_dis_alt:
+ clk_disable_unprepare(new_dram_alt_parent);
+out_dis_core:
+ clk_disable_unprepare(new_dram_core_parent);
+out:
+ return ret;
+}
+
+static int imx_ddrc_target(struct device *dev, unsigned long *freq, u32 flags)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+ struct imx_ddrc_freq *freq_info;
+ struct dev_pm_opp *new_opp;
+ unsigned long new_freq, cur_freq;
+ int ret;
+
+ new_opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR(new_opp)) {
+ ret = PTR_ERR(new_opp);
+ dev_err(dev, "failed to get recommended opp: %d\n", ret);
+ return ret;
+ }
+ new_freq = dev_pm_opp_get_freq(new_opp);
+ dev_pm_opp_put(new_opp);
+ cur_freq = clk_get_rate(priv->dram_core);
+
+ if (new_freq == cur_freq)
+ return 0;
+
+ freq_info = imx_ddrc_find_freq(priv, new_freq);
+ if (!freq_info)
+ return -EINVAL;
+ ret = imx_ddrc_set_freq(dev, freq_info);
+ if (ret)
+ dev_err(dev, "ddrc failed to change freq %lu to %lu\n",
+ cur_freq, new_freq);
+ else
+ dev_dbg(dev, "ddrc changed freq %lu to %lu\n",
+ cur_freq, new_freq);
+
+ return ret;
+}
+
+static int imx_ddrc_get_cur_freq(struct device *dev, unsigned long *freq)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+
+ *freq = clk_get_rate(priv->dram_core);
+
+ return 0;
+}
+
+static int imx_ddrc_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *stat)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+
+ stat->busy_time = 0;
+ stat->total_time = 0;
+ stat->current_frequency = clk_get_rate(priv->dram_core);
+
+ return 0;
+}
+
+static int imx_ddrc_init_freq_info(struct device *dev)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+ struct arm_smccc_res res;
+ int index;
+
+ /*
+ * An error here means DDR DVFS API not supported by firmware
+ */
+ arm_smccc_smc(IMX_SIP_DDR_DVFS, IMX_SIP_DDR_DVFS_GET_FREQ_COUNT,
+ 0, 0, 0, 0, 0, 0, &res);
+ priv->freq_count = res.a0;
+ if (priv->freq_count <= 0 || priv->freq_count > IMX_DDRC_MAX_FREQ_COUNT)
+ return -ENOSYS;
+
+ for (index = 0; index < priv->freq_count; ++index) {
+ struct imx_ddrc_freq *freq = &priv->freq_table[index];
+
+ arm_smccc_smc(IMX_SIP_DDR_DVFS, IMX_SIP_DDR_DVFS_GET_FREQ_INFO,
+ index, 0, 0, 0, 0, 0, &res);
+ /* Result should be strictly positive */
+ if ((long)res.a0 <= 0)
+ return -ENOSYS;
+
+ freq->rate = res.a0 * 250000;
+ freq->smcarg = index;
+ freq->dram_core_parent_index = res.a1;
+ freq->dram_alt_parent_index = res.a2;
+ freq->dram_apb_parent_index = res.a3;
+
+ /* dram_core has 2 options: dram_pll or dram_alt_root */
+ if (freq->dram_core_parent_index != 1 &&
+ freq->dram_core_parent_index != 2)
+ return -ENOSYS;
+ /* dram_apb and dram_alt have exactly 8 possible parents */
+ if (freq->dram_alt_parent_index > 8 ||
+ freq->dram_apb_parent_index > 8)
+ return -ENOSYS;
+ /* dram_core from alt requires explicit dram_alt parent */
+ if (freq->dram_core_parent_index == 2 &&
+ freq->dram_alt_parent_index == 0)
+ return -ENOSYS;
+ }
+
+ return 0;
+}
+
+static void imx_ddrc_exit(struct device *dev)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+
+ return dev_pm_opp_of_remove_table(dev);
+}
+
+static int imx_ddrc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct imx_ddrc *priv;
+ struct device_node *events_node;
+ const char *gov = DEVFREQ_GOV_USERSPACE;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ ret = imx_ddrc_init_freq_info(dev);
+ if (ret) {
+ dev_err(dev, "failed to init firmware freq info: %d\n", ret);
+ return ret;
+ }
+
+ priv->dram_core = devm_clk_get(dev, "dram_core");
+ priv->dram_pll = devm_clk_get(dev, "dram_pll");
+ priv->dram_alt = devm_clk_get(dev, "dram_alt");
+ priv->dram_alt_root = devm_clk_get(dev, "dram_alt_root");
+ priv->dram_apb = devm_clk_get(dev, "dram_apb");
+ if (IS_ERR(priv->dram_core) ||
+ IS_ERR(priv->dram_pll) ||
+ IS_ERR(priv->dram_alt) ||
+ IS_ERR(priv->dram_alt_root) ||
+ IS_ERR(priv->dram_apb)) {
+ ret = PTR_ERR(priv->devfreq);
+ dev_err(dev, "failed to fetch clocks: %d\n", ret);
+ return ret;
+ }
+
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to get OPP table\n");
+ return ret;
+ }
+
+ priv->profile.polling_ms = 1000;
+ priv->profile.target = imx_ddrc_target;
+ priv->profile.get_dev_status = imx_ddrc_get_dev_status;
+ priv->profile.exit = imx_ddrc_exit;
+ priv->profile.get_cur_freq = imx_ddrc_get_cur_freq;
+ priv->profile.initial_freq = clk_get_rate(priv->dram_core);
+
+ priv->devfreq = devm_devfreq_add_device(dev, &priv->profile,
+ gov, NULL);
+ if (IS_ERR(priv->devfreq)) {
+ ret = PTR_ERR(priv->devfreq);
+ dev_err(dev, "failed to add devfreq device: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+
+err:
+ dev_pm_opp_of_remove_table(dev);
+ return ret;
+}
+
+static const struct of_device_id imx_ddrc_of_match[] = {
+ { .compatible = "fsl,imx8m-ddrc", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, imx_ddrc_of_match);
+
+static struct platform_driver imx_ddrc_platdrv = {
+ .probe = imx_ddrc_probe,
+ .driver = {
+ .name = "imx-ddrc-devfreq",
+ .of_match_table = of_match_ptr(imx_ddrc_of_match),
+ },
+};
+module_platform_driver(imx_ddrc_platdrv);
+
+MODULE_DESCRIPTION("i.MX DDR controller frequency driver");
+MODULE_AUTHOR("Leonard Crestez <leonard.crestez@nxp.com>");
+MODULE_LICENSE("GPL v2");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/7] PM / devfreq: imx-ddrc: Measure bandwidth with perf
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
The imx8m ddrc has a performance monitoring block attached which can
be used to measure bandwidth usage and automatically adjust frequency.
There is already a perf driver for that block so instead of implementing
a devfreq events driver use the in-kernel perf API to implement
get_dev_status directly.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/devfreq/imx-ddrc.c | 136 ++++++++++++++++++++++++++++++++++++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/imx-ddrc.c b/drivers/devfreq/imx-ddrc.c
index e46a1e711bc6..d7f27cdce697 100644
--- a/drivers/devfreq/imx-ddrc.c
+++ b/drivers/devfreq/imx-ddrc.c
@@ -11,10 +11,13 @@
#include <linux/pm_opp.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/arm-smccc.h>
+#include <asm/perf_event.h>
+#include <linux/perf_event.h>
+
#define IMX_SIP_DDR_DVFS 0xc2000004
/* Values starting from 0 switch to specific frequency */
#define IMX_SIP_DDR_FREQ_SET_HIGH 0x00
@@ -81,10 +84,22 @@ struct imx_ddrc {
struct clk *dram_alt;
struct clk *dram_apb;
int freq_count;
struct imx_ddrc_freq freq_table[IMX_DDRC_MAX_FREQ_COUNT];
+
+ /* For measuring load with perf events: */
+ struct platform_device* pmu_pdev;
+ struct pmu *pmu;
+
+ struct perf_event_attr rd_event_attr;
+ struct perf_event_attr wr_event_attr;
+ struct perf_event *rd_event;
+ struct perf_event *wr_event;
+
+ u64 last_rd_val, last_rd_ena, last_rd_run;
+ u64 last_wr_val, last_wr_ena, last_wr_run;
};
static struct imx_ddrc_freq* imx_ddrc_find_freq(struct imx_ddrc* priv,
unsigned long rate)
{
@@ -233,17 +248,117 @@ static int imx_ddrc_get_cur_freq(struct device *dev, unsigned long *freq)
static int imx_ddrc_get_dev_status(struct device *dev,
struct devfreq_dev_status *stat)
{
struct imx_ddrc *priv = dev_get_drvdata(dev);
- stat->busy_time = 0;
- stat->total_time = 0;
stat->current_frequency = clk_get_rate(priv->dram_core);
+ if (priv->rd_event && priv->wr_event) {
+ u64 rd_delta, rd_val, rd_ena, rd_run;
+ u64 wr_delta, wr_val, wr_ena, wr_run;
+
+ rd_val = perf_event_read_value(priv->rd_event, &rd_ena, &rd_run);
+ wr_val = perf_event_read_value(priv->wr_event, &wr_ena, &wr_run);
+
+ rd_delta = (rd_val - priv->last_rd_val) * (rd_ena - priv->last_rd_ena) / (rd_run - priv->last_rd_run);
+ priv->last_rd_val = rd_val;
+ priv->last_rd_ena = rd_ena;
+ priv->last_rd_run = rd_run;
+ wr_delta = (wr_val - priv->last_wr_val) * (wr_ena - priv->last_wr_ena) / (wr_run - priv->last_wr_run);
+ priv->last_wr_val = wr_val;
+ priv->last_wr_ena = wr_ena;
+ priv->last_wr_run = wr_run;
+
+ /* magic numbers, possibly wrong */
+ stat->busy_time = 4 * (rd_delta + wr_delta);
+ stat->total_time = stat->current_frequency;
+ } else {
+ stat->busy_time = 0;
+ stat->total_time = 0;
+ }
+
+ return 0;
+}
+
+static int imx_ddrc_perf_disable(struct imx_ddrc *priv)
+{
+ /* release and set to NULL */
+ if (!IS_ERR_OR_NULL(priv->rd_event))
+ perf_event_release_kernel(priv->rd_event);
+ if (!IS_ERR_OR_NULL(priv->wr_event))
+ perf_event_release_kernel(priv->wr_event);
+ priv->rd_event = NULL;
+ priv->wr_event = NULL;
+
return 0;
}
+static int imx_ddrc_perf_enable(struct imx_ddrc *priv)
+{
+ int ret;
+
+ priv->rd_event_attr.size = sizeof(priv->rd_event_attr);
+ priv->rd_event_attr.type = priv->pmu->type;
+ priv->rd_event_attr.config = 0x2a;
+
+ priv->rd_event = perf_event_create_kernel_counter(
+ &priv->rd_event_attr, 0, NULL, NULL, NULL);
+ if (IS_ERR(priv->rd_event)) {
+ ret = PTR_ERR(priv->rd_event);
+ goto err;
+ }
+
+ priv->wr_event_attr.size = sizeof(priv->wr_event_attr);
+ priv->wr_event_attr.type = priv->pmu->type;
+ priv->wr_event_attr.config = 0x2b;
+
+ priv->wr_event = perf_event_create_kernel_counter(
+ &priv->wr_event_attr, 0, NULL, NULL, NULL);
+ if (IS_ERR(priv->wr_event)) {
+ ret = PTR_ERR(priv->wr_event);
+ goto err;
+ }
+
+ return 0;
+
+err:
+ imx_ddrc_perf_disable(priv);
+ return ret;
+}
+
+static int imx_ddrc_init_events(struct device *dev,
+ struct device_node* events_node)
+{
+ struct imx_ddrc *priv = dev_get_drvdata(dev);
+ struct device_driver *driver;
+
+ /*
+ * We need pmu->type for perf_event_attr but there is no API for
+ * mapping device_node to pmu. Fetch private data for imx-ddr-pmu and
+ * cast that to a struct pmu instead.
+ */
+ priv->pmu_pdev = of_find_device_by_node(events_node);
+ if (!priv->pmu_pdev)
+ return -EPROBE_DEFER;
+ driver = priv->pmu_pdev->dev.driver;
+ if (!driver)
+ return -EPROBE_DEFER;
+ if (strcmp(driver->name, "imx-ddr-pmu")) {
+ dev_warn(dev, "devfreq-events node %pOF has unexpected driver %s\n",
+ events_node, driver->name);
+ return -ENODEV;
+ }
+
+ priv->pmu = platform_get_drvdata(priv->pmu_pdev);
+ if (!priv->pmu)
+ return -EINVAL;
+
+ dev_info(dev, "events from pmu %s\n", priv->pmu->name);
+
+ return imx_ddrc_perf_enable(priv);
+}
+
static int imx_ddrc_init_freq_info(struct device *dev)
{
struct imx_ddrc *priv = dev_get_drvdata(dev);
struct arm_smccc_res res;
int index;
@@ -291,10 +406,13 @@ static int imx_ddrc_init_freq_info(struct device *dev)
static void imx_ddrc_exit(struct device *dev)
{
struct imx_ddrc *priv = dev_get_drvdata(dev);
+ imx_ddrc_perf_disable(priv);
+ platform_device_put(priv->pmu_pdev);
+
return dev_pm_opp_of_remove_table(dev);
}
static int imx_ddrc_probe(struct platform_device *pdev)
{
@@ -342,10 +460,22 @@ static int imx_ddrc_probe(struct platform_device *pdev)
priv->profile.get_dev_status = imx_ddrc_get_dev_status;
priv->profile.exit = imx_ddrc_exit;
priv->profile.get_cur_freq = imx_ddrc_get_cur_freq;
priv->profile.initial_freq = clk_get_rate(priv->dram_core);
+ /* Handle devfreq-events */
+ events_node = of_parse_phandle(dev->of_node, "devfreq-events", 0);
+ if (events_node) {
+ ret = imx_ddrc_init_events(dev, events_node);
+ of_node_put(events_node);
+ if (ret) {
+ dev_warn(dev, "failed to init perf events: %d\n", ret);
+ goto err;
+ }
+ gov = DEVFREQ_GOV_SIMPLE_ONDEMAND;
+ }
+
priv->devfreq = devm_devfreq_add_device(dev, &priv->profile,
gov, NULL);
if (IS_ERR(priv->devfreq)) {
ret = PTR_ERR(priv->devfreq);
dev_err(dev, "failed to add devfreq device: %d\n", ret);
@@ -353,10 +483,12 @@ static int imx_ddrc_probe(struct platform_device *pdev)
}
return 0;
err:
+ imx_ddrc_perf_disable(priv);
+ platform_device_put(priv->pmu_pdev);
dev_pm_opp_of_remove_table(dev);
return ret;
}
static const struct of_device_id imx_ddrc_of_match[] = {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/7] PM / devfreq: Add generic imx bus driver
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Add initial support for dynamic frequency switching on pieces of the imx
interconnect fabric.
All this driver actually does is set a clk rate based on an opp table.
No attempt is made to map registers or anything clever.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/devfreq/Kconfig | 12 +++
drivers/devfreq/Makefile | 1 +
drivers/devfreq/imx-devfreq.c | 148 ++++++++++++++++++++++++++++++++++
3 files changed, 161 insertions(+)
create mode 100644 drivers/devfreq/imx-devfreq.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index defe1d438710..9088a151bafe 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -90,10 +90,22 @@ config ARM_EXYNOS_BUS_DEVFREQ
Each memory bus group could contain many memoby bus block. It reads
PPMU counters of memory controllers by using DEVFREQ-event device
and adjusts the operating frequencies and voltages with OPP support.
This does not yet operate with optimal voltages.
+config ARM_IMX_DEVFREQ
+ tristate "i.MX DEVFREQ Driver"
+ depends on ARCH_MXC || COMPILE_TEST
+ select DEVFREQ_GOV_PASSIVE
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_GOV_USERSPACE
+ select PM_OPP
+ help
+ This adds the DEVFREQ driver for the i.MX family of SoCs.
+ It allows adjusting frequencies for DDRC (DDR Controller) and various
+ NICs and NOCs which form the SOC interconnect fabric
+
config ARM_TEGRA_DEVFREQ
tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver"
depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \
ARCH_TEGRA_132_SOC || ARCH_TEGRA_124_SOC || \
ARCH_TEGRA_210_SOC || \
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 338ae8440db6..c2463ed4c934 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -7,10 +7,11 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
+obj-$(CONFIG_ARM_IMX_DEVFREQ) += imx-devfreq.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra30-devfreq.o
obj-$(CONFIG_ARM_TEGRA20_DEVFREQ) += tegra20-devfreq.o
# DEVFREQ Event Drivers
diff --git a/drivers/devfreq/imx-devfreq.c b/drivers/devfreq/imx-devfreq.c
new file mode 100644
index 000000000000..702a4368af7d
--- /dev/null
+++ b/drivers/devfreq/imx-devfreq.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 NXP
+ */
+
+#include <linux/clk.h>
+#include <linux/devfreq.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pm_opp.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct imx_devfreq {
+ struct devfreq_dev_profile profile;
+ struct devfreq *devfreq;
+ struct clk *clk;
+ struct devfreq_passive_data passive_data;
+};
+
+static int imx_devfreq_target(struct device *dev, unsigned long *freq, u32 flags)
+{
+ struct imx_devfreq *priv = dev_get_drvdata(dev);
+ struct dev_pm_opp *new_opp;
+ unsigned long new_freq;
+ int ret;
+
+ new_opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR(new_opp)) {
+ ret = PTR_ERR(new_opp);
+ dev_err(dev, "failed to get recommended opp: %d\n", ret);
+ return ret;
+ }
+ new_freq = dev_pm_opp_get_freq(new_opp);
+ dev_pm_opp_put(new_opp);
+
+ return clk_set_rate(priv->clk, new_freq);
+}
+
+static int imx_devfreq_get_cur_freq(struct device *dev, unsigned long *freq)
+{
+ struct imx_devfreq *priv = dev_get_drvdata(dev);
+
+ *freq = clk_get_rate(priv->clk);
+
+ return 0;
+}
+
+static int imx_devfreq_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *stat)
+{
+ struct imx_devfreq *priv = dev_get_drvdata(dev);
+
+ stat->busy_time = 0;
+ stat->total_time = 0;
+ stat->current_frequency = clk_get_rate(priv->clk);
+
+ return 0;
+}
+
+static void imx_devfreq_exit(struct device *dev)
+{
+ return dev_pm_opp_of_remove_table(dev);
+}
+
+static int imx_devfreq_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct imx_devfreq *priv;
+ const char *gov = DEVFREQ_GOV_USERSPACE;
+ void *govdata = NULL;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(dev, "failed to fetch clk: %d\n", ret);
+ return ret;
+ }
+ platform_set_drvdata(pdev, priv);
+
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret < 0) {
+ dev_err(dev, "failed to get OPP table\n");
+ return ret;
+ }
+
+ priv->profile.polling_ms = 1000;
+ priv->profile.target = imx_devfreq_target;
+ priv->profile.get_dev_status = imx_devfreq_get_dev_status;
+ priv->profile.exit = imx_devfreq_exit;
+ priv->profile.get_cur_freq = imx_devfreq_get_cur_freq;
+ priv->profile.initial_freq = clk_get_rate(priv->clk);
+
+ /* Handle passive devfreq parent link */
+ priv->passive_data.parent = devfreq_get_devfreq_by_phandle(dev, 0);
+ if (!IS_ERR(priv->passive_data.parent)) {
+ dev_info(dev, "passive link to %s\n",
+ dev_name(priv->passive_data.parent->dev.parent));
+ gov = DEVFREQ_GOV_PASSIVE;
+ govdata = &priv->passive_data;
+ } else if (priv->passive_data.parent != ERR_PTR(-ENODEV)) {
+ // -ENODEV means no parent: not an error.
+ ret = PTR_ERR(priv->passive_data.parent);
+ if (ret != -EPROBE_DEFER)
+ dev_warn(dev, "failed to get passive parent: %d\n", ret);
+ goto err;
+ }
+
+ priv->devfreq = devm_devfreq_add_device(dev, &priv->profile,
+ gov, govdata);
+ if (IS_ERR(priv->devfreq)) {
+ ret = PTR_ERR(priv->devfreq);
+ dev_err(dev, "failed to add devfreq device: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+
+err:
+ dev_pm_opp_of_remove_table(dev);
+ return ret;
+}
+
+static const struct of_device_id imx_devfreq_of_match[] = {
+ { .compatible = "fsl,imx8m-noc", },
+ { .compatible = "fsl,imx8m-nic", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, imx_devfreq_of_match);
+
+static struct platform_driver imx_devfreq_platdrv = {
+ .probe = imx_devfreq_probe,
+ .driver = {
+ .name = "imx-devfreq",
+ .of_match_table = of_match_ptr(imx_devfreq_of_match),
+ },
+};
+module_platform_driver(imx_devfreq_platdrv);
+
+MODULE_DESCRIPTION("Generic i.MX bus frequency driver");
+MODULE_AUTHOR("Leonard Crestez <leonard.crestez@nxp.com>");
+MODULE_LICENSE("GPL v2");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/7] dt-bindings: devfreq: Add bindings for imx ddr controller
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Add devicetree bindings for the i.MX DDR Controller on imx8m series
chips. It supports dynamic frequency switching between multiple data
rates and this is exposed to Linux via the devfreq subsystem.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
.../devicetree/bindings/devfreq/imx-ddrc.yaml | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml
diff --git a/Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml b/Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml
new file mode 100644
index 000000000000..fa20280a682f
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/devfreq/imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: i.MX DDR Controller
+
+maintainers:
+ - Leonard Crestez <leonard.crestez@nxp.com>
+
+properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8m-ddrc
+
+ reg:
+ maxItems: 1
+ description: DDR Controller registers
+
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ items:
+ - const: dram_core
+ - const: dram_pll
+ - const: dram_alt_root
+ - const: dram_alt
+ - const: dram_apb
+
+required:
+ - reg
+ - compatible
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mm-clock.h>
+ ddrc: dram-controller@3d400000 {
+ compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc";
+ reg = <0x3d400000 0x400000>;
+ clock-names = "dram_core", "dram_pll", "dram_alt_root", "dram_alt", "dram_apb";
+ clocks = <&clk IMX8MM_CLK_DRAM_CORE>,
+ <&clk IMX8MM_DRAM_PLL>,
+ <&clk IMX8MM_CLK_DRAM_ALT_ROOT>,
+ <&clk IMX8MM_CLK_DRAM_ALT>,
+ <&clk IMX8MM_CLK_DRAM_APB>;
+ operating-points-v2 = <&ddrc_opp_table>;
+ };
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/7] dt-bindings: devfreq: Add bindings for generic imx buses
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Add initial dt bindings for the interconnects inside i.MX chips.
Multiple external IPs are involved but SOC integration means the
software controllable interfaces are very similar.
This is initially only for imx8mm but add an "fsl,imx8m-nic" fallback
similar to exynos-bus.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
.../devicetree/bindings/devfreq/imx.yaml | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/imx.yaml
diff --git a/Documentation/devicetree/bindings/devfreq/imx.yaml b/Documentation/devicetree/bindings/devfreq/imx.yaml
new file mode 100644
index 000000000000..0e2ee3a5205e
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/imx.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/devfreq/imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic i.MX bus frequency device
+
+maintainers:
+ - Leonard Crestez <leonard.crestez@nxp.com>
+
+description: |
+ The i.MX SoC family has multiple buses for which clock frequency (and sometimes
+ voltage) can be adjusted.
+
+ Some of those buses expose register areas mentioned in the memory maps as GPV
+ ("Global Programmers View") but not all. Access to this area might be denied for
+ normal world.
+
+ The buses are based on externally licensed IPs such as ARM NIC-301 and Arteris
+ FlexNOC but DT bindings are specific to the integration of these bus
+ interconnect IPs into imx SOCs.
+
+properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8m-noc
+ - fsl,imx8m-nic
+
+ reg:
+ maxItems: 1
+ description: GPV area
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8mm-clock.h>
+ noc: noc@32700000 {
+ compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc";
+ reg = <0x32700000 0x100000>;
+ clocks = <&clk IMX8MM_CLK_NOC>;
+ operating-points-v2 = <&noc_opp_table>;
+ };
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/7] clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram_alt/apb
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <cover.1565633880.git.leonard.crestez@nxp.com>
Dram frequency changes required modifying these clocks outside the
control of clk framework. Mark them as CLK_GET_RATE_NOCACHE so that
rates are always read back from registers.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/clk/imx/clk-imx8mm.c | 6 ++++--
drivers/clk/imx/clk-imx8mn.c | 6 ++++--
drivers/clk/imx/clk-imx8mq.c | 7 ++++---
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 1a944837f638..0417fa3c8e71 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -526,12 +526,14 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
/* IPG */
clks[IMX8MM_CLK_IPG_ROOT] = imx_clk_divider2("ipg_root", "ahb", base + 0x9080, 0, 1);
clks[IMX8MM_CLK_IPG_AUDIO_ROOT] = imx_clk_divider2("ipg_audio_root", "audio_ahb", base + 0x9180, 0, 1);
/* IP */
- clks[IMX8MM_CLK_DRAM_ALT] = imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000);
- clks[IMX8MM_CLK_DRAM_APB] = imx8m_clk_composite_critical("dram_apb", imx8mm_dram_apb_sels, base + 0xa080);
+ clks[IMX8MM_CLK_DRAM_ALT] = __imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000,
+ CLK_GET_RATE_NOCACHE);
+ clks[IMX8MM_CLK_DRAM_APB] = __imx8m_clk_composite("dram_apb", imx8mm_dram_apb_sels, base + 0xa080,
+ CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
clks[IMX8MM_CLK_VPU_G1] = imx8m_clk_composite("vpu_g1", imx8mm_vpu_g1_sels, base + 0xa100);
clks[IMX8MM_CLK_VPU_G2] = imx8m_clk_composite("vpu_g2", imx8mm_vpu_g2_sels, base + 0xa180);
clks[IMX8MM_CLK_DISP_DTRC] = imx8m_clk_composite("disp_dtrc", imx8mm_disp_dtrc_sels, base + 0xa200);
clks[IMX8MM_CLK_DISP_DC8000] = imx8m_clk_composite("disp_dc8000", imx8mm_disp_dc8000_sels, base + 0xa280);
clks[IMX8MM_CLK_PCIE1_CTRL] = imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels, base + 0xa300);
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index ecd1062f6847..1dda3e6c3019 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -497,12 +497,14 @@ static int imx8mn_clocks_probe(struct platform_device *pdev)
clks[IMX8MN_CLK_AHB] = imx8m_clk_composite_critical("ahb", imx8mn_ahb_sels, base + 0x9000);
clks[IMX8MN_CLK_AUDIO_AHB] = imx8m_clk_composite("audio_ahb", imx8mn_audio_ahb_sels, base + 0x9100);
clks[IMX8MN_CLK_IPG_ROOT] = imx_clk_divider2("ipg_root", "ahb", base + 0x9080, 0, 1);
clks[IMX8MN_CLK_IPG_AUDIO_ROOT] = imx_clk_divider2("ipg_audio_root", "audio_ahb", base + 0x9180, 0, 1);
clks[IMX8MN_CLK_DRAM_CORE] = imx_clk_mux2_flags("dram_core_clk", base + 0x9800, 24, 1, imx8mn_dram_core_sels, ARRAY_SIZE(imx8mn_dram_core_sels), CLK_IS_CRITICAL);
- clks[IMX8MN_CLK_DRAM_ALT] = imx8m_clk_composite("dram_alt", imx8mn_dram_alt_sels, base + 0xa000);
- clks[IMX8MN_CLK_DRAM_APB] = imx8m_clk_composite_critical("dram_apb", imx8mn_dram_apb_sels, base + 0xa080);
+ clks[IMX8MN_CLK_DRAM_ALT] = __imx8m_clk_composite("dram_alt", imx8mn_dram_alt_sels, base + 0xa000,
+ CLK_GET_RATE_NOCACHE);
+ clks[IMX8MN_CLK_DRAM_APB] = __imx8m_clk_composite("dram_apb", imx8mn_dram_apb_sels, base + 0xa080,
+ CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
clks[IMX8MN_CLK_DISP_PIXEL] = imx8m_clk_composite("disp_pixel", imx8mn_disp_pixel_sels, base + 0xa500);
clks[IMX8MN_CLK_SAI2] = imx8m_clk_composite("sai2", imx8mn_sai2_sels, base + 0xa600);
clks[IMX8MN_CLK_SAI3] = imx8m_clk_composite("sai3", imx8mn_sai3_sels, base + 0xa680);
clks[IMX8MN_CLK_SAI5] = imx8m_clk_composite("sai5", imx8mn_sai5_sels, base + 0xa780);
clks[IMX8MN_CLK_SAI6] = imx8m_clk_composite("sai6", imx8mn_sai6_sels, base + 0xa800);
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index e451e68eaa84..f18206d57020 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -436,13 +436,14 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_CLK_IPG_ROOT] = imx_clk_divider2("ipg_root", "ahb", base + 0x9080, 0, 1);
clks[IMX8MQ_CLK_IPG_AUDIO_ROOT] = imx_clk_divider2("ipg_audio_root", "audio_ahb", base + 0x9180, 0, 1);
/* IP */
clks[IMX8MQ_CLK_DRAM_CORE] = imx_clk_mux2_flags("dram_core_clk", base + 0x9800, 24, 1, imx8mq_dram_core_sels, ARRAY_SIZE(imx8mq_dram_core_sels), CLK_IS_CRITICAL);
-
- clks[IMX8MQ_CLK_DRAM_ALT] = imx8m_clk_composite("dram_alt", imx8mq_dram_alt_sels, base + 0xa000);
- clks[IMX8MQ_CLK_DRAM_APB] = imx8m_clk_composite_critical("dram_apb", imx8mq_dram_apb_sels, base + 0xa080);
+ clks[IMX8MQ_CLK_DRAM_ALT] = __imx8m_clk_composite("dram_alt", imx8mq_dram_alt_sels, base + 0xa000,
+ CLK_GET_RATE_NOCACHE);
+ clks[IMX8MQ_CLK_DRAM_APB] = __imx8m_clk_composite("dram_apb", imx8mq_dram_apb_sels, base + 0xa080,
+ CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
clks[IMX8MQ_CLK_VPU_G1] = imx8m_clk_composite("vpu_g1", imx8mq_vpu_g1_sels, base + 0xa100);
clks[IMX8MQ_CLK_VPU_G2] = imx8m_clk_composite("vpu_g2", imx8mq_vpu_g2_sels, base + 0xa180);
clks[IMX8MQ_CLK_DISP_DTRC] = imx8m_clk_composite("disp_dtrc", imx8mq_disp_dtrc_sels, base + 0xa200);
clks[IMX8MQ_CLK_DISP_DC8000] = imx8m_clk_composite("disp_dc8000", imx8mq_disp_dc8000_sels, base + 0xa280);
clks[IMX8MQ_CLK_PCIE1_CTRL] = imx8m_clk_composite("pcie1_ctrl", imx8mq_pcie1_ctrl_sels, base + 0xa300);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/7] PM / devfreq: Add initial imx support
From: Leonard Crestez @ 2019-08-12 18:49 UTC (permalink / raw)
To: Stephen Boyd, MyungJoo Ham, Kyungmin Park, Rob Herring
Cc: Dong Aisheng, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, Chanwoo Choi,
Will Deacon, Alexandre Bailon, kernel, Fabio Estevam,
Mark Rutland, Shawn Guo, Georgi Djakov, devicetree, Jacky Bai
This adds devfreq support for imx8mm, covering dynamic scaling of
internal NOC and DDR Controller
Scaling for simple busses (NIC/NOC) is done through the clk framework
while DRAM scaling is performed in firmware with an "imx-ddrc" wrapper
for devfreq.
Changes since RFCv3:
* Implement passive support and set NOC parent to DDRC
* Drop scaling AHB/AXI for now (NOC/DDRC use most power anyway)
* Split into two devreq drivers (and bindings) because the ddrc is
really a distinct piece of hardware.
* Stop relying on clk_min_rate
* Fetch info about dram clk parents from firmware instead of
hardcoding in driver. This can more easily support additional rates.
* Perform DRAM frequency inside devfreq instead of clk, mostly due to
objections to earlier RFCs for "imx8m-dram-clk"
* Link: https://patchwork.kernel.org/cover/11056779/
* Link: https://patchwork.kernel.org/patch/11049429/
Stephen: It would be very helpful if you could comment on the dram
frequency switching code. I moved it outside of clk but now I have to
use provider APIs outside of drivers/clk for parent manipulation. Few
other drivers do that so maybe it's OK?
Scaling buses can cause problems for devices with realtime bandwith
requirements such as display, the intention is to use the interconnect
framework to make DEV_PM_QOS_MIN_FREQUENCY to devfreq. There are
separate patches for that:
* https://patchwork.kernel.org/patch/11084279/
* https://patchwork.kernel.org/cover/11078671/
Leonard Crestez (7):
clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram_alt/apb
dt-bindings: devfreq: Add bindings for generic imx buses
PM / devfreq: Add generic imx bus driver
dt-bindings: devfreq: Add bindings for imx ddr controller
PM / devfreq: Add dynamic scaling for imx ddr controller
PM / devfreq: imx-ddrc: Measure bandwidth with perf
arm64: dts: imx8mm: Add devfreq nodes
.../devicetree/bindings/devfreq/imx-ddrc.yaml | 53 ++
.../devicetree/bindings/devfreq/imx.yaml | 50 ++
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 51 +-
drivers/clk/imx/clk-imx8mm.c | 6 +-
drivers/clk/imx/clk-imx8mn.c | 6 +-
drivers/clk/imx/clk-imx8mq.c | 7 +-
drivers/devfreq/Kconfig | 12 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/imx-ddrc.c | 511 ++++++++++++++++++
drivers/devfreq/imx-devfreq.c | 148 +++++
10 files changed, 837 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml
create mode 100644 Documentation/devicetree/bindings/devfreq/imx.yaml
create mode 100644 drivers/devfreq/imx-ddrc.c
create mode 100644 drivers/devfreq/imx-devfreq.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Harald Geyer @ 2019-08-12 18:22 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Robin Murphy, arm-linux
In-Reply-To: <CA+E=qVchsqOF_hVD-qBuKwi7PTMYtUR-LE2dD_mpptFJcWE_yw@mail.gmail.com>
Vasily Khoruzhick writes:
> OK, so what should we do? 'perf top'/'perf record' work fine if PMU
> node is dropped, but they don't work if PMU node is present (even with
> interrupts dropped).
Really? Even if you tell it to only listen to software events? (Which
is the only thing you get without a PMU anyway, I believe.)
> I'd prefer to have 'perf top' and 'perf record'
> working instead of 'perf stat'
I think, if a broken PMU confuses 'perf top' beyond usability, it
should be fixed.
Harald
--
Nationalratswahl: Ich trete als unabhängiger Experte für Klimaschutz
und freie Software an! Ich will mit Vorzugsstimmen ins Parlament kommen,
weil wenn ich es nicht mache, kümmert sich womöglich niemand darum.
https://haraldgeyer.at
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-12 18:01 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <20190812080420.saelmqb36vkelxn4@flea>
On Mon, Aug 12, 2019 at 1:04 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Aug 08, 2019 at 12:59:07PM -0700, Vasily Khoruzhick wrote:
> > On Thu, Aug 8, 2019 at 9:26 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Wed, Aug 07, 2019 at 10:36:08AM -0700, Vasily Khoruzhick wrote:
> > > > On Wed, Aug 7, 2019 at 4:56 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > >
> > > > > On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> > > > > > On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > > >
> > > > > > > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > > > > > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > > > > > > >>
> > > > > > > >> Vasily Khoruzhick writes:
> > > > > > > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > > > >>>>
> > > > > > > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > > > > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > > > > >>>>> as result 'perf top' shows no events.
> > > > > > > >>>>
> > > > > > > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > > > > > >>>> It could well just be that the interrupt numbers are wrong...
> > > > > > > >>>
> > > > > > > >>> Looks like it does, at least result looks plausible:
> > > > > > > >>
> > > > > > > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > > > > > > >>
> > > > > > > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > > > > > > >> the interrupts part of the node, when I added it. So I'm not too
> > > > > > > >> surprised I got it wrong.
> > > > > > > >>
> > > > > > > >> However, it would be unfortunate if the node got removed completely,
> > > > > > > >> because perf stat would not work anymore. Maybe we can only remove
> > > > > > > >> the interrupts or just fix them even if the HW doesn't work?
> > > > > > > >
> > > > > > > > I'm not familiar with PMU driver. Is it possible to get it working
> > > > > > > > without interrupts?
> > > > > > >
> > > > > > > Yup - you get a grumpy message from the driver, it will refuse sampling
> > > > > > > events (the ones which weren't working anyway), and if you measure
> > > > > > > anything for long enough that a counter overflows you'll get wonky
> > > > > > > results. But for counting hardware events over relatively short periods
> > > > > > > it'll still do the job.
> > > > > >
> > > > > > I tried to drop interrupts completely from the node but 'perf top' is
> > > > > > still broken. Though now in different way: it complains "cycles: PMU
> > > > > > Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> > > > > > stat'"
> > > > >
> > > > > I have no idea if that's the culprit, but what is the state of the
> > > > > 0x09010000 register?
> > > >
> > > > What register is that and how do I check it?
> > >
> > > It's in the CPUX Configuration block, and the bits are labelled as CPU
> > > Debug Reset.
> > >
> > > And if you have busybox, you can use devmem.
> >
> > CPUX configuration block is at 0x01700000 according to A64 user
> > manual, and particular register you're interested in is at 0x01700080,
> > its value is 0x1110110F.
> >
> > Bits 16-19 are not defined in user manual and are not set.
>
> Sorry, I somehow thought this was for the H6...
>
> I don't have any idea then :/
OK, so what should we do? 'perf top'/'perf record' work fine if PMU
node is dropped, but they don't work if PMU node is present (even with
interrupts dropped). I'd prefer to have 'perf top' and 'perf record'
working instead of 'perf stat'
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] ARM: dts: meson8b: odroidc1: use the MAC address stored in the eFuse
From: Martin Blumenstingl @ 2019-08-12 17:50 UTC (permalink / raw)
To: linux-amlogic, khilman
Cc: narmstrong, ottuzzi, linux-kernel, Martin Blumenstingl,
linux-arm-kernel
In-Reply-To: <20190812175004.24943-1-martin.blumenstingl@googlemail.com>
Odroid-C1 uses the MAC address stored in eFuse at offset 0x1b4 (which is
defined as a "standard" offset for all Meson8 and Meson8b boards, but
testing shows that MXQ doesn't have the eFuse values programmed and
EC-100 stores it's MAC address in eMMC).
Add the nvmem cell which points to the MAC address and asssign it to the
Ethernet controller as "mac-address".
As result of this the MAC address which is stored in the eFuse is now
assigned to the Ethernet controller and consistent across reboots.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm/boot/dts/meson8b-odroidc1.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts
index 90f66dc45115..a24eccc354b9 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -190,6 +190,12 @@
cpu-supply = <&vcck>;
};
+&efuse {
+ ethernet_mac_address: mac@1b4 {
+ reg = <0x1b4 0x6>;
+ };
+};
+
ðmac {
status = "okay";
@@ -200,6 +206,9 @@
phy-handle = <ð_phy>;
amlogic,tx-delay-ns = <4>;
+ nvmem-cells = <ðernet_mac_address>;
+ nvmem-cell-names = "mac-address";
+
mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/1] ARM: dts: meson8b: persistent MAC address for Odroid-C1
From: Martin Blumenstingl @ 2019-08-12 17:50 UTC (permalink / raw)
To: linux-amlogic, khilman
Cc: narmstrong, ottuzzi, linux-kernel, Martin Blumenstingl,
linux-arm-kernel
This series makes Odroid-C1 use the MAC address which is programmed into
the eFuse.
build-time dependencies:
none
runtime dependencies (without these a random MAC address is assigned,
just like before these patches), both are already part of -next:
- "nvmem: meson-mx-efuse: allow reading data smaller than word_size"
from [1]
- "net: stmmac: manage errors returned by of_get_mac_address()" from [1]
Changes since v1 at [2]:
- only add the nvmem cell to meson8b-odroidc1.dts as suggested by Neil.
It turns out that neither MXQ and EC-100 have the MAC address in eFuse
(which means only 1/3 boards has it at the given eFuse offset, so it's
not worth having it the common .dtsi)
Kevin: you already have v1 of this series in your tree. Feel free to
replace the two patches from v1 with this single one.
[0] https://patchwork.kernel.org/patch/11062659/
[1] https://patchwork.kernel.org/patch/11062657/
[2] https://patchwork.kernel.org/cover/11062663/
Martin Blumenstingl (1):
ARM: dts: meson8b: odroidc1: use the MAC address stored in the eFuse
arch/arm/boot/dts/meson8b-odroidc1.dts | 9 +++++++++
1 file changed, 9 insertions(+)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 254 boots: 11 failed, 227 passed with 16 offline (v5.3-rc4-5755-g8e72ac275c63)
From: Mark Brown @ 2019-08-12 17:37 UTC (permalink / raw)
To: Bjorn Andersson, Andy Gross
Cc: linux-arm-msm, linux-next, linux-arm-kernel, kernel-build-reports
In-Reply-To: <5d519859.1c69fb81.531c0.088a@mx.google.com>
[-- Attachment #1.1: Type: text/plain, Size: 833 bytes --]
On Mon, Aug 12, 2019 at 09:48:25AM -0700, kernelci.org bot wrote:
Today's -next fails to boot on qcs404-evb-4k:
> arm64:
> defconfig:
> gcc-8:
The boot appears to suddenly drop into a bootloader near the end of
boot:
05:14:44.500307 [ 1.886858] Key type dns_resolver registered
05:14:44.500345 [ 1.892544] registered taskstats version 1
05:14:44.500382 [ 1.895502] Loading compiled-in X.509 certificates
05:14:44.515903 [ 1.916067] hctosys: unable to open rtc device (rtc0)
05:14:51.562124
05:14:51.562251 Format: Log Type - Time(microsec) - Message - Optional Info
05:14:51.562306 Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
05:14:51.562383 S - QC_IMAGE_VERSION_STRING=BOOT.XF.0.1-00080-QCS405LZB-2
05:14:51.562427 S - IMAGE_VARIANT_STRING=Qcs405LA
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Catalin Marinas @ 2019-08-12 17:36 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Vincenzo Frascino, Dave P Martin,
linux-arm-kernel
In-Reply-To: <68354acd-e205-71cb-11c6-74a150178ae0@intel.com>
On Fri, Aug 09, 2019 at 07:10:18AM -0700, Dave Hansen wrote:
> On 8/8/19 10:27 AM, Catalin Marinas wrote:
> > On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:
> >> Also, shouldn't this be converted over to an arch_prctl()?
> >
> > What do you mean by arch_prctl()? We don't have such thing, apart from
> > maybe arch_prctl_spec_ctrl_*(). We achieve the same thing with the
> > {SET,GET}_TAGGED_ADDR_CTRL macros. They could be renamed to
> > arch_prctl_tagged_addr_{set,get} or something but I don't see much
> > point.
>
> Silly me. We have an x86-specific:
>
> SYSCALL_DEFINE2(arch_prctl, int , option, unsigned long , arg2)
>
> I guess there's no ARM equivalent so you're stuck with the generic one.
>
> > What would be better (for a separate patch series) is to clean up
> > sys_prctl() and move the arch-specific options into separate
> > arch_prctl() under arch/*/kernel/. But it's not really for this series.
>
> I think it does make sense for truly arch-specific features to stay out
> of the arch-generic prctl(). Yes, I know I've personally violated this
> in the past. :)
Maybe Dave M could revive his prctl() clean-up patches which moves the
arch specific cases to the corresponding arch/*/ code
> >> What is the scope of these prctl()'s? Are they thread-scoped or
> >> process-scoped? Can two threads in the same process run with different
> >> tagging ABI modes?
> >
> > Good point. They are thread-scoped and this should be made clear in the
> > doc. Two threads can have different modes.
> >
> > The expectation is that this is invoked early during process start (by
> > the dynamic loader or libc init) while in single-thread mode and
> > subsequent threads will inherit the same mode. However, other uses are
> > possible.
>
> If that's the expectation, it would be really nice to codify it.
> Basically, you can't enable the feature if another thread is already
> been forked off.
Well, that's my expectation but I'm not a userspace developer. I don't
think there is any good reason to prevent it. It doesn't cost us
anything to support in the kernel, other than making the documentation
clearer.
> >>> +When a process has successfully enabled the new ABI by invoking
> >>> +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following
> >>> +behaviours are guaranteed:
> >>> +
> >>> +- Every currently available syscall, except the cases mentioned in section
> >>> + 3, can accept any valid tagged pointer. The same rule is applicable to
> >>> + any syscall introduced in the future.
> >>> +
> >>> +- The syscall behaviour is undefined for non valid tagged pointers.
> >>
> >> Do you really mean "undefined"? I mean, a bad pointer is a bad pointer.
> >> Why should it matter if it's a tagged bad pointer or an untagged bad
> >> pointer?
> >
> > Szabolcs already replied here. We may have tagged pointers that can be
> > dereferenced just fine but being passed to the kernel may not be well
> > defined (e.g. some driver doing a find_vma() that fails unless it
> > explicitly untags the address). It's as undefined as the current
> > behaviour (without these patches) guarantees.
>
> It might just be nicer to point out what this features *changes* about
> invalid pointer handling, which is nothing. :) Maybe:
>
> The syscall behaviour for invalid pointers is the same for both
> tagged and untagged pointers.
Good point.
> >>> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> >>> + PR_SET_MM_MAP_SIZE.
> >>> +
> >>> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> >>> +
> >>> +Any attempt to use non-zero tagged pointers will lead to undefined
> >>> +behaviour.
> >>
> >> I wonder if you want to generalize this a bit. I think you're saying
> >> that parts of the ABI that modify the *layout* of the address space
> >> never accept tagged pointers.
> >
> > I guess our difficulty in specifying this may have been caused by
> > over-generalising. For example, madvise/mprotect came under the same
> > category but there is a use-case for malloc'ed pointers (and tagged) to
> > the kernel (e.g. MADV_DONTNEED). If we can restrict the meaning to
> > address space *layout* manipulation, we'd have mmap/mremap/munmap,
> > brk/sbrk, prctl(PR_SET_MM). Did I miss anything?. Other related syscalls
> > like mprotect/madvise preserve the layout while only changing permissions,
> > backing store, so the would be allowed to accept tags.
>
> shmat() comes to mind. I also did a quick grep for mmap_sem taken for
> write and didn't see anything else obvious jump out at me.
I'll document shmat() as not supported, together with the prctl().
As I submitted a fixup already, I propose that we allow tagged pointers
on mmap/munmap/mremap/brk. It makes the documentation simpler ;) (and
the user understanding of what is and is not allowed).
> >> It looks like the TAG_SHIFT and tag size are pretty baked into the
> >> aarch64 architecture. But, are you confident that no future
> >> implementations will want different positions or sizes? (obviously
> >> controlled by other TCR_EL1 bits)
> >
> > For the top-byte-ignore (TBI), that's been baked in the architecture
> > since ARMv8.0 and we'll have to keep the backwards compatible mode. As
> > the name implies, it's the top byte of the address and that's what the
> > document above refers to.
> >
> > With MTE, I can't exclude other configurations in the future but I'd
> > expect the kernel to present the option as a new HWCAP and the user to
> > explicitly opt in via a new prctl() flag. I seriously doubt we'd break
> > existing binaries. So, yes TAG_SHIFT may be different but so would the
> > prctl() above.
>
> Basically, what you have is a "turn tagging on" and "turn tagging off"
> call which are binary: all on or all off. How about exposing a mask:
>
> /* Replace hard-coded mask size/position: */
> unsigned long mask = prctl(GET_POSSIBLE_TAGGED_ADDR_BITS);
>
> if (mask == 0)
> // no tagging is supported obviously
>
> prctl(SET_TAGGED_ADDR_BITS, mask);
>
> // now userspace knows via 'mask' where the tag bits are
For the actual hardware memory tagging, maybe we could get the possible
bits but for TBI, as I said above, that's baked into the architecture. I
don't think it's worth the effort of getting a mask as I don't see ARM
changing this without breaking existing software. Even compiler support
like hwasan relies on the 8-bit TBI.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Ray Jui @ 2019-08-12 17:33 UTC (permalink / raw)
To: Rayagonda Kokatanur, Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Shivaraj Shetty,
linux-kernel, Icarus Chau, bcm-kernel-feedback-list, linux-i2c,
linux-arm-kernel
In-Reply-To: <1565150941-27297-1-git-send-email-rayagonda.kokatanur@broadcom.com>
Hi Wolfram,
On 8/6/19 9:09 PM, Rayagonda Kokatanur wrote:
> From: Lori Hikichi <lori.hikichi@broadcom.com>
>
> Enable handling of i2c repeated start. The current code
> handles a multi msg i2c transfer as separate i2c bus
> transactions. This change will now handle this case
> using the i2c repeated start protocol. The number of msgs
> in a transfer is limited to two, and must be a write
> followed by a read.
>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> Signed-off-by: Icarus Chau <icarus.chau@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Signed-off-by: Shivaraj Shetty <sshetty1@broadcom.com>
> ---
Note this patch has gone through internal review and testing on various
I2C slave devices. It is introduced to work around limitation of our I2C
controller and allows it to work on certain I2C slave devices that are
sensitive and requires repeated start between transactions instead of a
stop.
Given that my name is also on the Signed-off-by since I helped to
rewrite part of the patch, I'm not going to add my Reviewed-by tag here.
Please help to review.
Thanks,
Ray
> drivers/i2c/busses/i2c-bcm-iproc.c | 70 +++++++++++++++++++++++++++++++-------
> 1 file changed, 57 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index d7fd76b..15fedcf 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -81,6 +81,7 @@
> #define M_CMD_PROTOCOL_MASK 0xf
> #define M_CMD_PROTOCOL_BLK_WR 0x7
> #define M_CMD_PROTOCOL_BLK_RD 0x8
> +#define M_CMD_PROTOCOL_PROCESS 0xa
> #define M_CMD_PEC_SHIFT 8
> #define M_CMD_RD_CNT_SHIFT 0
> #define M_CMD_RD_CNT_MASK 0xff
> @@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct bcm_iproc_i2c_dev *iproc_i2c,
> return 0;
> }
>
> -static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> - struct i2c_msg *msg)
> +/*
> + * If 'process_call' is true, then this is a multi-msg transfer that requires
> + * a repeated start between the messages.
> + * More specifically, it must be a write (reg) followed by a read (data).
> + * The i2c quirks are set to enforce this rule.
> + */
> +static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
> + struct i2c_msg *msgs, bool process_call)
> {
> int i;
> u8 addr;
> u32 val, tmp, val_intr_en;
> unsigned int tx_bytes;
> + struct i2c_msg *msg = &msgs[0];
>
> /* check if bus is busy */
> if (!!(iproc_i2c_rd_reg(iproc_i2c,
> @@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> val = msg->buf[i];
>
> /* mark the last byte */
> - if (i == msg->len - 1)
> - val |= BIT(M_TX_WR_STATUS_SHIFT);
> + if (!process_call && (i == msg->len - 1))
> + val |= 1 << M_TX_WR_STATUS_SHIFT;
>
> iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
> }
> iproc_i2c->tx_bytes = tx_bytes;
> }
>
> + /* Process the read message if this is process call */
> + if (process_call) {
> + msg++;
> + iproc_i2c->msg = msg; /* point to second msg */
> +
> + /*
> + * The last byte to be sent out should be a slave
> + * address with read operation
> + */
> + addr = msg->addr << 1 | 1;
> + /* mark it the last byte out */
> + val = addr | (1 << M_TX_WR_STATUS_SHIFT);
> + iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
> + }
> +
> /* mark as incomplete before starting the transaction */
> if (iproc_i2c->irq)
> reinit_completion(&iproc_i2c->done);
> @@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> * underrun interrupt, which will be triggerred when the TX FIFO is
> * empty. When that happens we can then pump more data into the FIFO
> */
> - if (!(msg->flags & I2C_M_RD) &&
> + if (!process_call && !(msg->flags & I2C_M_RD) &&
> msg->len > iproc_i2c->tx_bytes)
> val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
>
> @@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> */
> val = BIT(M_CMD_START_BUSY_SHIFT);
> if (msg->flags & I2C_M_RD) {
> + u32 protocol;
> +
> iproc_i2c->rx_bytes = 0;
> if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
> iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
> @@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
> /* enable the RX threshold interrupt */
> val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
>
> - val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
> + protocol = process_call ?
> + M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
> +
> + val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
> (msg->len << M_CMD_RD_CNT_SHIFT);
> } else {
> val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
> @@ -774,17 +802,31 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
> struct i2c_msg msgs[], int num)
> {
> struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(adapter);
> - int ret, i;
> + bool process_call = false;
> + int ret;
>
> - /* go through all messages */
> - for (i = 0; i < num; i++) {
> - ret = bcm_iproc_i2c_xfer_single_msg(iproc_i2c, &msgs[i]);
> - if (ret) {
> - dev_dbg(iproc_i2c->device, "xfer failed\n");
> - return ret;
> + if (num > 2) {
> + dev_err(iproc_i2c->device,
> + "Only support up to 2 messages. Current msg count %d\n",
> + num);
> + return -EOPNOTSUPP;
> + }
> +
> + if (num == 2) {
> + /* Repeated start, use process call */
> + process_call = true;
> + if (msgs[1].flags & I2C_M_NOSTART) {
> + dev_err(iproc_i2c->device, "Invalid repeated start\n");
> + return -EOPNOTSUPP;
> }
> }
>
> + ret = bcm_iproc_i2c_xfer_internal(iproc_i2c, msgs, process_call);
> + if (ret) {
> + dev_dbg(iproc_i2c->device, "xfer failed\n");
> + return ret;
> + }
> +
> return num;
> }
>
> @@ -806,6 +848,8 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
> };
>
> static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> + .flags = I2C_AQ_COMB_WRITE_THEN_READ,
> + .max_comb_1st_msg_len = M_TX_RX_FIFO_SIZE,
> .max_read_len = M_RX_MAX_READ_LEN,
> };
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/2] i2c: iproc: Add full name of devicetree node to adapter name
From: Ray Jui @ 2019-08-12 17:29 UTC (permalink / raw)
To: Rayagonda Kokatanur, Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, linux-kernel,
bcm-kernel-feedback-list, linux-i2c, linux-arm-kernel
In-Reply-To: <1565235473-28461-3-git-send-email-rayagonda.kokatanur@broadcom.com>
On 8/7/19 8:37 PM, Rayagonda Kokatanur wrote:
> From: Lori Hikichi <lori.hikichi@broadcom.com>
>
> Add the full name of the devicetree node to the adapter name.
> Without this change, all adapters have the same name making it difficult
> to distinguish between multiple instances.
> The most obvious way to see this is to use the utility i2c_detect.
> e.g. "i2c-detect -l"
>
> Before
> i2c-1 i2c Broadcom iProc I2C adapter I2C adapter
> i2c-0 i2c Broadcom iProc I2C adapter I2C adapter
>
> After
> i2c-1 i2c Broadcom iProc (i2c@e0000) I2C adapter
> i2c-0 i2c Broadcom iProc (i2c@b0000) I2C adapter
>
> Now it is easy to figure out which adapter maps to a which DT node.
>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
> drivers/i2c/busses/i2c-bcm-iproc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index 19ef2b0..183b220 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -922,7 +922,9 @@ static int bcm_iproc_i2c_probe(struct platform_device *pdev)
>
> adap = &iproc_i2c->adapter;
> i2c_set_adapdata(adap, iproc_i2c);
> - strlcpy(adap->name, "Broadcom iProc I2C adapter", sizeof(adap->name));
> + snprintf(adap->name, sizeof(adap->name),
> + "Broadcom iProc (%s)",
> + of_node_full_name(iproc_i2c->device->of_node));
> adap->algo = &bcm_iproc_algo;
> adap->quirks = &bcm_iproc_i2c_quirks;
> adap->dev.parent = &pdev->dev;
>
Looks good, thanks!
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] i2c: iproc: Stop advertising support of SMBUS quick cmd
From: Ray Jui @ 2019-08-12 17:29 UTC (permalink / raw)
To: Rayagonda Kokatanur, Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, linux-kernel,
bcm-kernel-feedback-list, linux-i2c, linux-arm-kernel
In-Reply-To: <1565235473-28461-2-git-send-email-rayagonda.kokatanur@broadcom.com>
On 8/7/19 8:37 PM, Rayagonda Kokatanur wrote:
> From: Lori Hikichi <lori.hikichi@broadcom.com>
>
> The driver does not support the SMBUS Quick command so remove the
> flag that indicates that level of support.
> By default the i2c_detect tool uses the quick command to try and
> detect devices at some bus addresses. If the quick command is used
> then we will not detect the device, even though it is present.
>
> Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver)
>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
> ---
> drivers/i2c/busses/i2c-bcm-iproc.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index d7fd76b..19ef2b0 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -790,7 +790,10 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
>
> static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
> {
> - u32 val = I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> + u32 val;
> +
> + /* We do not support the SMBUS Quick command */
> + val = I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
>
> if (adap->algo->reg_slave)
> val |= I2C_FUNC_SLAVE;
>
Change looks good to me. Thanks.
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 285 boots: 16 failed, 264 passed with 3 offline, 1 untried/unknown, 1 conflict (next-20190718)
From: Mark Brown @ 2019-08-12 17:24 UTC (permalink / raw)
To: khilman, Heiko Stuebner
Cc: linux-rockchip, linux-next, linux-arm-kernel,
kernel-build-reports
In-Reply-To: <20190718162005.GF5761@sirena.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1084 bytes --]
On Thu, Jul 18, 2019 at 05:20:05PM +0100, Mark Brown wrote:
> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
> Today's -next started failing to boot defconfig on rk3399-firefly:
> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
> [ 87.495335] ------------[ cut here ]------------
> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> I'm struggling to see anything relevant in the diff from yesterday, the
> unlisted frequency warnings were there in the logs yesterday but no oops
> and I'm not seeing any changes in cpufreq, clk or anything relevant
> looking.
> Full bootlog and other info can be found here:
>
> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
This is still present in -next today, though we don't have the failure
to change frequency any more - it still fails right after cpufreq
though:
https://kernelci.org/boot/id/5d51784259b514a021f12245/
https://kernelci.org/boot/id/5d51781559b514a007f12241/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Catalin Marinas @ 2019-08-12 17:17 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Dave Hansen, Vincenzo Frascino,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190812104606.GY56241@e119886-lin.cambridge.arm.com>
On Mon, Aug 12, 2019 at 11:46:06AM +0100, Andrew Murray wrote:
> On Thu, Aug 08, 2019 at 06:04:24PM +0100, Will Deacon wrote:
> > On Wed, Aug 07, 2019 at 04:53:20PM +0100, Catalin Marinas wrote:
> > > +
> > > +- mmap() addr parameter.
> > > +
> > > +- mremap() new_address parameter.
> > > +
> > > +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> > > + PR_SET_MM_MAP_SIZE.
> > > +
> > > +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> >
> > How did you generate this list and who will keep it up to date? How do you
> > know you haven't missed anything?
>
> What about shared memory system calls: shmat, shmdt? The latest "arm64: untag
> user pointers passed to the kernel" series doesn't untag these, thus we should
> indicate here that these too are no supported.
Yes. We dropped them from a previous version of the series but they've
never been documented. I'll add something (unless someone has a real
use-case for using tags with shmat/shmdt).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: smp: disable hotplug on trusted OS resident CPU
From: Sudeep Holla @ 2019-08-12 17:11 UTC (permalink / raw)
To: Will Deacon; +Cc: Mark Rutland, Catalin Marinas, linux-arm-kernel
In-Reply-To: <ae9944d8-0c0a-5f0f-707d-4d9e70a4f163@arm.com>
Hi Will,
(sorry for responding so late, I seem to have lost your reply and
when I saw the patch today in my git, searched and saw this reply)
On Mon, Aug 12, 2019 at 06:00:52PM +0100, Sudeep Holla wrote:
>
> On 13/06/2019 10:14, Will Deacon wrote:
> > Hi Sudeep.
> >
> > On Wed, Jun 12, 2019 at 01:51:37PM +0100, Sudeep Holla wrote:
> >> The trusted OS may reject CPU_OFF calls to its resident CPU, so we must
> >> avoid issuing those. We never migrate a Trusted OS and we already take
> >> care to prevent CPU_OFF PSCI call. However, this is not reflected
> >> explicitly to the userspace. Any user can attempt to hotplug trusted OS
> >> resident CPU. The entire motion of going through the various state
> >> transitions in the CPU hotplug state machine gets executed and the
> >> PSCI layer finally refuses to make CPU_OFF call.
> >>
> >> This results is unnecessary unwinding of CPU hotplug state machine in
> >> the kernel. Instead we can mark the trusted OS resident CPU as not
> >> available for hotplug, so that the user attempt or request to do the
> >> same will get immediately rejected.
> >>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Will Deacon <will.deacon@arm.com>
> >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >> ---
> >> arch/arm64/include/asm/cpu_ops.h | 3 +++
> >> arch/arm64/kernel/psci.c | 6 ++++++
> >> arch/arm64/kernel/setup.c | 11 ++++++++++-
> >> 3 files changed, 19 insertions(+), 1 deletion(-)
> >
> > I'm just trying to understand the motivation behind this. It's not a fix as
> > far as I can tell, but more of an optimisation for a failing CPU hotplug
> > case. Why is that important? I feel like I'm missing something.
> >
Yes it's just optimisation and not a fix. The main reasons I came up
with this was to avoid unnecessary CPU hotplug state machine unwinding
as it's generally heavy weight operation. There's no other hidden
reasons :) that you are missing.
IIRC I wrote this when I was debugging some issue with suspend-to-ram
which was broken for a different reason.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/3] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
From: Krzysztof Kozlowski @ 2019-08-12 16:59 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20190812165909.12387-1-krzk@kernel.org>
Add support for i.MX6UL modules from Kontron Electronics GmbH (before
acquisition: Exceet Electronics) and evalkit boards based on it:
1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
(LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
256 MB NAND and other interfaces,
2. N6310 S: evalkit, w/wo eMMC, without display,
3. N6310 S 43: evalkit with 4.3" display,
The work is based on Exceet/Kontron source code (GPLv2) with numerous
changes:
1. Reorganize files,
2. Rename Exceet -> Kontron,
3. Rename models/compatibles to match newest Kontron product naming,
4. Fix coding style errors and adjust to device tree coding guidelines,
5. Fix DTC warnings,
6. Extend compatibles so eval boards inherit the SoM compatible,
7. Use defines instead of GPIO and interrupt flag values,
8. Use proper vendor compatible for Macronix SPI NOR,
9. Replace deprecated bindings with proper ones,
10. Sort nodes alphabetically,
11. Remove Admatec display nodes (not yet supported).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
---
Changes since v4:
None
Changes since v3, after Shawn's review:
1. Split bindings update to patch 2/3,
2. Remove unsupported displays from (Admatec),
3. Remove N6310 S 50 board (same as N6310 S 43 since there is no Admatec
display),
4. Order iomux nodes by name, minor cleanup,
5. Use wakeup-source instead of enable-sdio-wakeup,
6. Add review tags.
Changes since v2, after Fabio's review:
1. Add "imx6ul" compatible to board name (that's what I understood from
review),
2. Add vendor/device prefix to eeprom and document the compatible,
3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
AG in Switzerland (also making LCD panels),
4. Use generic names for nodes,
5. Use IRQ_TYPE_LEVEL_LOW,
6. Move iomux to the end of files,
7. Remove regulators node (include regulators in top level),
8. Remove cpu clock-frequency,
9. Other minor fixes pointed by Fabio.
Changes since v1, after Frieder's review:
1. Remove unneeded license notes,
2. Add Kontron copyright (2018),
3. Rename the files/models/compatibles to new naming - N6310,
4. Remove unneeded CPU operating points override,
5. Switch regulator nodes into simple children nodes without addresses
(so not simple bus),
6. Use proper vendor compatible for Macronix SPI NOR.
---
.../devicetree/bindings/arm/fsl.yaml | 3 +
arch/arm/boot/dts/Makefile | 2 +
.../boot/dts/imx6ul-kontron-n6310-s-43.dts | 102 +++++
arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 420 ++++++++++++++++++
.../boot/dts/imx6ul-kontron-n6310-som.dtsi | 134 ++++++
5 files changed, 661 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..d07b3c06d7cf 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,6 +161,9 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
+ - kontron,imx6ul-n6310-som # Kontron N6310 SOM
+ - kontron,imx6ul-n6310-s # Kontron N6310 S Board
+ - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..747eef501f95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -569,6 +569,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-geam.dtb \
imx6ul-isiot-emmc.dtb \
imx6ul-isiot-nand.dtb \
+ imx6ul-kontron-n6310-s.dtb \
+ imx6ul-kontron-n6310-s-43.dtb \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
new file mode 100644
index 000000000000..5bad29683cc3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+#include "imx6ul-kontron-n6310-s.dts"
+
+/ {
+ model = "Kontron N6310 S 43";
+ compatible = "kontron,imx6ul-n6310-s-43", "kontron,imx6ul-n6310-s",
+ "kontron,imx6ul-n6310-som", "fsl,imx6ul";
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm7 0 5000000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+};
+
+&i2c4 {
+ touchscreen@5d {
+ compatible = "goodix,gt928";
+ reg = <0x5d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cap_touch>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+ irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
+ /* Leave status disabled because of missing display panel node */
+};
+
+&pwm7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_cap_touch: captouchgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
+ MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
+ MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
+ >;
+ };
+
+ pinctrl_lcdif_ctrl: lcdifctrlgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
+ MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
+ >;
+ };
+
+ pinctrl_lcdif_dat: lcdifdatgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
+ MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
+ MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
+ MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
+ MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
+ MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
+ MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
new file mode 100644
index 000000000000..0205fd56d975
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+/dts-v1/;
+
+#include "imx6ul-kontron-n6310-som.dtsi"
+
+/ {
+ model = "Kontron N6310 S";
+ compatible = "kontron,imx6ul-n6310-s", "kontron,imx6ul-n6310-som",
+ "fsl,imx6ul";
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led1 {
+ label = "debug-led1";
+ gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+
+ led2 {
+ label = "debug-led2";
+ gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led3 {
+ label = "debug-led3";
+ gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ pwm-beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm8 0 5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_adc: regulator-vref-adc {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-adc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&adc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc1>;
+ num-channels = <3>;
+ vref-supply = <®_vref_adc>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "anvo,anv32e61w", "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ spi-cpha;
+ spi-cpol;
+ pagesize = <1>;
+ size = <8192>;
+ address-width = <16>;
+ };
+};
+
+&fec1 {
+ pinctrl-0 = <&pinctrl_enet1>;
+ /delete-node/ mdio;
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet2 &pinctrl_enet2_mdio>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy2>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+
+ ethphy2: ethernet-phy@2 {
+ reg = <2>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET2_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ rtc@32 {
+ compatible = "epson,rx8900";
+ reg = <0x32>;
+ };
+};
+
+&pwm8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm8>;
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ linux,rs485-enabled-at-boot-time;
+ rs485-rx-during-tx;
+ rs485-rts-active-low;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1>;
+ dr_mode = "otg";
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ vbus-supply = <®_usb_otg1_vbus>;
+ status = "okay";
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ keep-power-in-suspend;
+ wakeup-source;
+ vmmc-supply = <®_3v3>;
+ voltage-ranges = <3300 3300>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ vmmc-supply = <®_3v3>;
+ voltage-ranges = <3300 3300>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_reset_out &pinctrl_gpio>;
+
+ pinctrl_adc1: adc1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
+ MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0xb0
+ >;
+ };
+
+ /* FRAM */
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_DATA07__ECSPI1_MISO 0x100b1
+ MX6UL_PAD_CSI_DATA06__ECSPI1_MOSI 0x100b1
+ MX6UL_PAD_CSI_DATA04__ECSPI1_SCLK 0x100b1
+ MX6UL_PAD_CSI_DATA05__GPIO4_IO26 0x100b1 /* ECSPI1-CS1 */
+ >;
+ };
+
+ pinctrl_enet2: enet2grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b009
+ >;
+ };
+
+ pinctrl_enet2_mdio: enet2mdiogrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp{
+ fsl,pins = <
+ MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x1b020
+ MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x1b020
+ >;
+ };
+
+ pinctrl_gpio: gpiogrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0 /* DOUT1 */
+ MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x1b0b0 /* DIN1 */
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x1b0b0 /* DOUT2 */
+ MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x1b0b0 /* DIN2 */
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_TX_DATA__GPIO1_IO30 0x1b0b0 /* LED H14 */
+ MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x1b0b0 /* LED H15 */
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0 /* LED H16 */
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_PIXCLK__I2C1_SCL 0x4001b8b0
+ MX6UL_PAD_CSI_MCLK__I2C1_SDA 0x4001b8b0
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_TX_DATA__I2C4_SCL 0x4001f8b0
+ MX6UL_PAD_UART2_RX_DATA__I2C4_SDA 0x4001f8b0
+ >;
+ };
+
+ pinctrl_pwm8: pwm8grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_HSYNC__PWM8_OUT 0x110b0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_DATA04__UART2_DCE_TX 0x1b0b1
+ MX6UL_PAD_NAND_DATA05__UART2_DCE_RX 0x1b0b1
+ MX6UL_PAD_NAND_DATA06__UART2_DCE_CTS 0x1b0b1
+ /*
+ * mux unused RTS to make sure it doesn't cause
+ * any interrupts when it is undefined
+ */
+ MX6UL_PAD_NAND_DATA07__UART2_DCE_RTS 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6UL_PAD_UART3_TX_DATA__UART3_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART3_RX_DATA__UART3_DCE_RX 0x1b0b1
+ MX6UL_PAD_UART3_CTS_B__UART3_DCE_CTS 0x1b0b1
+ MX6UL_PAD_UART3_RTS_B__UART3_DCE_RTS 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_TX_DATA__UART4_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART4_RX_DATA__UART4_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg1: usbotg1 {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x100b1 /* SD1_CD */
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10059
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100b9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170b9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170b9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170b9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170b9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
new file mode 100644
index 000000000000..a896b2348dd2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+#include "imx6ul.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Kontron N6310 SOM";
+ compatible = "kontron,imx6ul-n6310-som", "fsl,imx6ul";
+
+ memory@80000000 {
+ reg = <0x80000000 0x10000000>;
+ device_type = "memory";
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "mxicy,mx25v8035f", "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1_mdio>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&fec2 {
+ phy-mode = "rmii";
+ status = "disabled";
+};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-nand";
+ spi-max-frequency = <108000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ reg = <0>;
+
+ partition@0 {
+ label = "ubi1";
+ reg = <0x00000000 0x08000000>;
+ };
+
+ partition@8000000 {
+ label = "ubi2";
+ reg = <0x08000000 0x08000000>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reset_out>;
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_DATA03__ECSPI2_MISO 0x100b1
+ MX6UL_PAD_CSI_DATA02__ECSPI2_MOSI 0x100b1
+ MX6UL_PAD_CSI_DATA00__ECSPI2_SCLK 0x100b1
+ MX6UL_PAD_CSI_DATA01__GPIO4_IO22 0x100b1
+ >;
+ };
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b009
+ >;
+ };
+
+ pinctrl_enet1_mdio: enet1mdiogrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ >;
+ };
+
+ pinctrl_qspi: qspigrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_WP_B__QSPI_A_SCLK 0x70a1
+ MX6UL_PAD_NAND_READY_B__QSPI_A_DATA00 0x70a1
+ MX6UL_PAD_NAND_CE0_B__QSPI_A_DATA01 0x70a1
+ MX6UL_PAD_NAND_CE1_B__QSPI_A_DATA02 0x70a1
+ MX6UL_PAD_NAND_CLE__QSPI_A_DATA03 0x70a1
+ MX6UL_PAD_NAND_DQS__QSPI_A_SS0_B 0x70a1
+ >;
+ };
+
+ pinctrl_reset_out: rstoutgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
+ >;
+ };
+};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: eeprom: at25: Add Anvo ANV32E61W
From: Krzysztof Kozlowski @ 2019-08-12 16:59 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20190812165909.12387-1-krzk@kernel.org>
Document the compatible for ANV32E61W 64kb Serial SPI non-volatile SRAM.
Although it is a SRAM device, it can be accessed through EEPROM
interface. At least until there is no proper SRAM driver support for
it.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
---
Changes since v4:
1. Update commit msg.
---
Documentation/devicetree/bindings/eeprom/at25.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
index b3bde97dc199..42577dd113dd 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.txt
+++ b/Documentation/devicetree/bindings/eeprom/at25.txt
@@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
Required properties:
- compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
Example "<vendor>,<type>" values:
+ "anvo,anv32e61w"
"microchip,25lc040"
"st,m95m02"
"st,m95256"
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: vendor-prefixes: Add Anvo-Systems
From: Krzysztof Kozlowski @ 2019-08-12 16:59 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: Krzysztof Kozlowski
Add vendor prefix for Anvo-Systems Dresden GmbH.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v4:
None
Changes since v3:
1. Add Rob's tag,
2. Remove Admatec (not needed anymore).
Changes since v2:
1. Use admatecde vendor prefix.
2. Add Anvo-Systems Dresden GmbH.
Changes since v1:
New patch
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..519889f5aec8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -81,6 +81,8 @@ patternProperties:
description: Analogix Semiconductor, Inc.
"^andestech,.*":
description: Andes Technology Corporation
+ "^anvo,.*":
+ description: Anvo-Systems Dresden GmbH
"^apm,.*":
description: Applied Micro Circuits Corporation (APM)
"^aptina,.*":
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Andrew F. Davis @ 2019-08-12 16:48 UTC (permalink / raw)
To: Suman Anna, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <ea1efb4e-43be-4efc-10f8-9d182313bf12@ti.com>
On 8/12/19 12:39 PM, Suman Anna wrote:
> On 8/12/19 11:36 AM, Andrew F. Davis wrote:
>> On 8/12/19 12:28 PM, Suman Anna wrote:
>>> On 8/12/19 10:47 AM, Andrew F. Davis wrote:
>>>> On 10/23/18 9:19 PM, Suman Anna wrote:
>>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>>> printing the vring buffer address. This prints only a hashed
>>>>> pointer even for previliged users. Use "%pK" instead so that
>>>>> the address can be printed during debug using kptr_restrict
>>>>> sysctl.
>>>>>
>>>>
>>>>
>>>> s/previliged/privileged
>>>
>>> Bjorn,
>>> Can you fix this up when applying.
>>>
>>>>
>>>> You describe what the code does, but not why you need this. %pK is used
>>>> for only about 1% of pointer printing, why do you want to leak this
>>>> address to userspace at all?
>>>
>>> Andrew,
>>> Default behavior of %pK is same as %p, but it does allow you to control
>>> the print. The reason is clearly mentioned in the last sentence in the
>>> patch description.
>>>
>>
>>
>> Let me rephrase then, why would you ever set 'kptr_restrict' to anything
>> other than 0, or why do you want to be able to leak this address to
>> userspace at all? If the answer is just because you can, then all 12,000
>> instances of %p in kernel could be converted for the same reason.
>
> It is a dev_dbg statement, so it is already under dynamic debug control.
> We would only ever use it during debug.
>
Most pointer printings are in debug statements..
I'm simply not seeing what this helps us do. The DMA address I can
understand, it may be given to a remote core so we may want to verify it
is the same on both sides, but the actual virtual kernel address is of
no value to us, a hash to track it across uses is just as good.
Andrew
> regards
> Suman
>
>>
>> Andrew
>>
>>
>>> regards
>>> Suman
>>>
>>>>
>>>> Andrew
>>>>
>>>>
>>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>>> ---
>>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> index f29dee731026..1345f373a1a0 100644
>>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>>> goto vqs_del;
>>>>> }
>>>>>
>>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>>>> bufs_va, &vrp->bufs_dma);
>>>>>
>>>>> /* half of the buffers is dedicated for RX */
>>>>>
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rpmsg: virtio_rpmsg_bus: replace "%p" with "%pK"
From: Suman Anna @ 2019-08-12 16:39 UTC (permalink / raw)
To: Andrew F. Davis, Bjorn Andersson
Cc: linux-arm-kernel, linux-remoteproc, linux-kernel, Loic Pallardy
In-Reply-To: <92dc4403-8782-8dbf-b912-cc832ac748a7@ti.com>
On 8/12/19 11:36 AM, Andrew F. Davis wrote:
> On 8/12/19 12:28 PM, Suman Anna wrote:
>> On 8/12/19 10:47 AM, Andrew F. Davis wrote:
>>> On 10/23/18 9:19 PM, Suman Anna wrote:
>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>> printing the vring buffer address. This prints only a hashed
>>>> pointer even for previliged users. Use "%pK" instead so that
>>>> the address can be printed during debug using kptr_restrict
>>>> sysctl.
>>>>
>>>
>>>
>>> s/previliged/privileged
>>
>> Bjorn,
>> Can you fix this up when applying.
>>
>>>
>>> You describe what the code does, but not why you need this. %pK is used
>>> for only about 1% of pointer printing, why do you want to leak this
>>> address to userspace at all?
>>
>> Andrew,
>> Default behavior of %pK is same as %p, but it does allow you to control
>> the print. The reason is clearly mentioned in the last sentence in the
>> patch description.
>>
>
>
> Let me rephrase then, why would you ever set 'kptr_restrict' to anything
> other than 0, or why do you want to be able to leak this address to
> userspace at all? If the answer is just because you can, then all 12,000
> instances of %p in kernel could be converted for the same reason.
It is a dev_dbg statement, so it is already under dynamic debug control.
We would only ever use it during debug.
regards
Suman
>
> Andrew
>
>
>> regards
>> Suman
>>
>>>
>>> Andrew
>>>
>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> ---
>>>> drivers/rpmsg/virtio_rpmsg_bus.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> index f29dee731026..1345f373a1a0 100644
>>>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>>>> @@ -950,7 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
>>>> goto vqs_del;
>>>> }
>>>>
>>>> - dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n",
>>>> + dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n",
>>>> bufs_va, &vrp->bufs_dma);
>>>>
>>>> /* half of the buffers is dedicated for RX */
>>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox