Devicetree
 help / color / mirror / Atom feed
* [PATCH v4 5/5] regulator: qcom: labibb: Add SC interrupt handling
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
  To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
  Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
	rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>

From: Nisha Kumari <nishakumari@codeaurora.org>

Add Short circuit interrupt handling and recovery for the lab and ibb
regulators on qcom platforms.

The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
notification which will be triggered on short circuit. They should
try to enable the regulator once, and if it doesn't get enabled,
handle shutting down the panel accordingly.

Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
    [sumits: updated to rework to use regmap_read_poll_timeout, handle it per
             regulator, add REGULATOR_EVENT_OVER_CURRENT handling and
             notification to clients and other cleanup]
--
v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
     per-regulator instead of clearing both lab and ibb errors on either irq
     triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
     notification to clients.
v3: sumits: updated as per review comments of v2: removed spurious check for
     irq in handler and some unused variables; inlined some of the code,
     omitted IRQF_TRIGGER_RISING as it's coming from DT.
v4: sumits: updated 'int vreg_enabled' to 'boot enabled', made sc_irq a local var
     and other review comments from v3.
---
 drivers/regulator/qcom-labibb-regulator.c | 102 +++++++++++++++++++++-
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/qcom-labibb-regulator.c b/drivers/regulator/qcom-labibb-regulator.c
index 33b764ac69d1..bca0308b26dd 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0-only
 // Copyright (c) 2020, The Linux Foundation. All rights reserved.
 
+#include <linux/interrupt.h>
 #include <linux/module.h>
 #include <linux/of_irq.h>
 #include <linux/of.h>
@@ -18,6 +19,7 @@
 #define REG_LABIBB_ENABLE_CTL		0x46
 #define LABIBB_STATUS1_VREG_OK_BIT	BIT(7)
 #define LABIBB_CONTROL_ENABLE		BIT(7)
+#define LABIBB_STATUS1_SC_DETECT_BIT	BIT(6)
 
 #define LAB_ENABLE_CTL_MASK		BIT(7)
 #define IBB_ENABLE_CTL_MASK		(BIT(7) | BIT(6))
@@ -27,12 +29,16 @@
 #define IBB_ENABLE_TIME			(LABIBB_OFF_ON_DELAY * 10)
 #define LABIBB_POLL_ENABLED_TIME	1000
 
+#define POLLING_SCP_DONE_INTERVAL_US	5000
+#define POLLING_SCP_TIMEOUT		16000
+
 struct labibb_regulator {
 	struct regulator_desc		desc;
 	struct device			*dev;
 	struct regmap			*regmap;
 	struct regulator_dev		*rdev;
 	u16				base;
+	bool				enabled;
 	u8				type;
 };
 
@@ -59,12 +65,26 @@ static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
 
 static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
 {
-	return regulator_enable_regmap(rdev);
+	int ret;
+	struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+	ret = regulator_enable_regmap(rdev);
+	if (ret >= 0)
+		reg->enabled = true;
+
+	return ret;
 }
 
 static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
 {
-	return regulator_disable_regmap(rdev);
+	int ret = 0;
+	struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+	ret = regulator_disable_regmap(rdev);
+	if (ret >= 0)
+		reg->enabled = false;
+
+	return ret;
 }
 
 static struct regulator_ops qcom_labibb_ops = {
@@ -73,12 +93,70 @@ static struct regulator_ops qcom_labibb_ops = {
 	.is_enabled		= qcom_labibb_regulator_is_enabled,
 };
 
+static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
+{
+	int ret;
+	u16 reg;
+	unsigned int val;
+	struct labibb_regulator *labibb_reg = _reg;
+	bool in_sc_err, scp_done = false;
+
+	ret = regmap_read(labibb_reg->regmap,
+			  labibb_reg->base + REG_LABIBB_STATUS1, &val);
+	if (ret < 0) {
+		dev_err(labibb_reg->dev, "sc_err_irq: Read failed, ret=%d\n",
+			ret);
+		return IRQ_HANDLED;
+	}
+
+	dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
+		labibb_reg->desc.name, val);
+
+	in_sc_err = !!(val & LABIBB_STATUS1_SC_DETECT_BIT);
+
+	/*
+	 * The SC(short circuit) fault would trigger PBS(Portable Batch
+	 * System) to disable regulators for protection. This would
+	 * cause the SC_DETECT status being cleared so that it's not
+	 * able to get the SC fault status.
+	 * Check if the regulator is enabled in the driver but
+	 * disabled in hardware, this means a SC fault had happened
+	 * and SCP handling is completed by PBS.
+	 */
+	if (!in_sc_err) {
+
+		reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
+
+		ret = regmap_read_poll_timeout(labibb_reg->regmap,
+					reg, val,
+					!(val & LABIBB_CONTROL_ENABLE),
+					POLLING_SCP_DONE_INTERVAL_US,
+					POLLING_SCP_TIMEOUT);
+
+		if (!ret && labibb_reg->enabled) {
+			dev_dbg(labibb_reg->dev,
+				"%s has been disabled by SCP\n",
+				labibb_reg->desc.name);
+			scp_done = true;
+		}
+	}
+
+	if (in_sc_err || scp_done) {
+		regulator_lock(labibb_reg->rdev);
+		regulator_notifier_call_chain(labibb_reg->rdev,
+						REGULATOR_EVENT_OVER_CURRENT,
+						NULL);
+		regulator_unlock(labibb_reg->rdev);
+	}
+	return IRQ_HANDLED;
+}
+
 static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *reg,
 				const struct labibb_regulator_data *reg_data,
 				struct device_node *of_node)
 {
 	struct regulator_config cfg = {};
-	int ret;
+	int ret, sc_irq;
 
 	reg->base = reg_data->base;
 	reg->type = reg_data->type;
@@ -95,6 +173,24 @@ static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *
 	reg->desc.poll_enabled_time = LABIBB_POLL_ENABLED_TIME;
 	reg->desc.off_on_delay = LABIBB_OFF_ON_DELAY;
 
+	sc_irq = of_irq_get_byname(of_node, "sc-err");
+	if (sc_irq < 0) {
+		dev_err(reg->dev, "Unable to get sc-err, ret = %d\n",
+			sc_irq);
+		return ERR_PTR(sc_irq);
+	} else {
+		ret = devm_request_threaded_irq(reg->dev,
+						sc_irq,
+						NULL, labibb_sc_err_handler,
+						IRQF_ONESHOT,
+						"sc-err", reg);
+		if (ret) {
+			dev_err(reg->dev, "Failed to register sc-err irq ret=%d\n",
+				ret);
+			return ERR_PTR(ret);
+		}
+	}
+
 	cfg.dev = reg->dev;
 	cfg.driver_data = reg;
 	cfg.regmap = reg->regmap;
-- 
2.26.2


^ permalink raw reply related

* [PATCH v4 4/5] regulator: qcom: Add labibb driver
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
  To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
  Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
	rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>

From: Nisha Kumari <nishakumari@codeaurora.org>

Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.

This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.

Signed-off-by: Nisha Kumari <nishakumari@codeaurora.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
  [sumits: reworked to driver for more common code, using core regulator
    features, and using newly-added poll_enabled_time functionality
    from core]
--
v2: sumits: reworked the driver for more common code, and addressed
     review comments from v1
v3: sumits: addressed review comments from v2; moved to use core
     regulator features like enable_time, off_on_delay, and the newly
     added poll_enabled_time. Moved the check_enabled functionality
     to core framework via poll_enabled_time.
v4: sumits: address review comments from v3, including cleaning up
     register_labibb_regulator(), and adapted to updated meaning of
     poll_enabled_time.

---
 drivers/regulator/Kconfig                 |  10 ++
 drivers/regulator/Makefile                |   1 +
 drivers/regulator/qcom-labibb-regulator.c | 193 ++++++++++++++++++++++
 3 files changed, 204 insertions(+)
 create mode 100644 drivers/regulator/qcom-labibb-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb098ef..58704a9fd05d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
 	  This driver provides support for the voltage regulators on the
 	  WM8994 CODEC.
 
+config REGULATOR_QCOM_LABIBB
+	tristate "QCOM LAB/IBB regulator support"
+	depends on SPMI || COMPILE_TEST
+	help
+	  This driver supports Qualcomm's LAB/IBB regulators present on the
+	  Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+	  based PMIC implementations. LAB can be used as positive
+	  boost regulator and IBB can be used as a negative boost regulator
+	  for LCD display panel.
+
 endif
 
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee001d9a..5b313786c0e8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323)	+= mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6358)	+= mt6358-regulator.o
 obj-$(CONFIG_REGULATOR_MT6380)	+= mt6380-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397)	+= mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index 000000000000..33b764ac69d1
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
+
+#define REG_PERPH_TYPE                  0x04
+#define QCOM_LAB_TYPE			0x24
+#define QCOM_IBB_TYPE			0x20
+
+#define REG_LABIBB_STATUS1		0x08
+#define REG_LABIBB_ENABLE_CTL		0x46
+#define LABIBB_STATUS1_VREG_OK_BIT	BIT(7)
+#define LABIBB_CONTROL_ENABLE		BIT(7)
+
+#define LAB_ENABLE_CTL_MASK		BIT(7)
+#define IBB_ENABLE_CTL_MASK		(BIT(7) | BIT(6))
+
+#define LABIBB_OFF_ON_DELAY		1000
+#define LAB_ENABLE_TIME			(LABIBB_OFF_ON_DELAY * 2)
+#define IBB_ENABLE_TIME			(LABIBB_OFF_ON_DELAY * 10)
+#define LABIBB_POLL_ENABLED_TIME	1000
+
+struct labibb_regulator {
+	struct regulator_desc		desc;
+	struct device			*dev;
+	struct regmap			*regmap;
+	struct regulator_dev		*rdev;
+	u16				base;
+	u8				type;
+};
+
+struct labibb_regulator_data {
+	u16				base;
+	const char			*name;
+	u8				type;
+	unsigned int			enable_time;
+	unsigned int			enable_mask;
+};
+
+static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
+{
+	int ret;
+	unsigned int val;
+	struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+	ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, &val);
+	if (ret < 0) {
+		dev_err(reg->dev, "Read register failed ret = %d\n", ret);
+		return ret;
+	}
+	return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
+}
+
+static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
+{
+	return regulator_enable_regmap(rdev);
+}
+
+static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
+{
+	return regulator_disable_regmap(rdev);
+}
+
+static struct regulator_ops qcom_labibb_ops = {
+	.enable			= qcom_labibb_regulator_enable,
+	.disable		= qcom_labibb_regulator_disable,
+	.is_enabled		= qcom_labibb_regulator_is_enabled,
+};
+
+static struct regulator_dev *register_labibb_regulator(struct labibb_regulator *reg,
+				const struct labibb_regulator_data *reg_data,
+				struct device_node *of_node)
+{
+	struct regulator_config cfg = {};
+	int ret;
+
+	reg->base = reg_data->base;
+	reg->type = reg_data->type;
+	reg->desc.enable_mask = reg_data->enable_mask;
+	reg->desc.enable_reg = reg->base + REG_LABIBB_ENABLE_CTL;
+	reg->desc.enable_val = LABIBB_CONTROL_ENABLE;
+	reg->desc.of_match = reg_data->name;
+	reg->desc.name = reg_data->name;
+	reg->desc.owner = THIS_MODULE;
+	reg->desc.type = REGULATOR_VOLTAGE;
+	reg->desc.ops = &qcom_labibb_ops;
+
+	reg->desc.enable_time = reg_data->enable_time;
+	reg->desc.poll_enabled_time = LABIBB_POLL_ENABLED_TIME;
+	reg->desc.off_on_delay = LABIBB_OFF_ON_DELAY;
+
+	cfg.dev = reg->dev;
+	cfg.driver_data = reg;
+	cfg.regmap = reg->regmap;
+	cfg.of_node = of_node;
+
+	return devm_regulator_register(reg->dev, &reg->desc, &cfg);
+}
+
+static const struct labibb_regulator_data pmi8998_labibb_data[] = {
+	{0xde00, "lab", QCOM_LAB_TYPE, LAB_ENABLE_TIME, LAB_ENABLE_CTL_MASK},
+	{0xdc00, "ibb", QCOM_IBB_TYPE, IBB_ENABLE_TIME, IBB_ENABLE_CTL_MASK},
+	{ },
+};
+
+static const struct of_device_id qcom_labibb_match[] = {
+	{ .compatible = "qcom,pmi8998-lab-ibb", .data = &pmi8998_labibb_data},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, qcom_labibb_match);
+
+static int qcom_labibb_regulator_probe(struct platform_device *pdev)
+{
+	struct labibb_regulator *labibb_reg;
+	struct device *dev = &pdev->dev;
+	struct device_node *child;
+	const struct of_device_id *match;
+	const struct labibb_regulator_data *reg_data;
+	struct regmap *reg_regmap;
+	unsigned int type;
+	int ret;
+
+	reg_regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!reg_regmap) {
+		dev_err(&pdev->dev, "Couldn't get parent's regmap\n");
+		return -ENODEV;
+	}
+
+	match = of_match_device(qcom_labibb_match, &pdev->dev);
+	if (!match)
+		return -ENODEV;
+
+	for (reg_data = match->data; reg_data->name; reg_data++) {
+		child = of_get_child_by_name(pdev->dev.of_node, reg_data->name);
+
+		if (WARN_ON(child == NULL))
+			return -EINVAL;
+
+		/* Validate if the type of regulator is indeed
+		 * what's mentioned in DT.
+		 */
+		ret = regmap_read(reg_regmap, reg_data->base + REG_PERPH_TYPE,
+				  &type);
+		if (ret < 0) {
+			dev_err(dev,
+				"Peripheral type read failed ret=%d\n",
+				ret);
+			return -EINVAL;
+		}
+
+		if (WARN_ON((type != QCOM_LAB_TYPE) && (type != QCOM_IBB_TYPE)) ||
+		    WARN_ON(type != reg_data->type))
+			return -EINVAL;
+
+		labibb_reg  = devm_kzalloc(&pdev->dev, sizeof(*labibb_reg),
+					   GFP_KERNEL);
+		if (!labibb_reg)
+			return -ENOMEM;
+
+		labibb_reg->regmap = reg_regmap;
+		labibb_reg->dev = dev;
+
+		dev_info(dev, "Registering %s regulator\n", child->full_name);
+
+		labibb_reg->rdev = register_labibb_regulator(labibb_reg, reg_data, child);
+		if (IS_ERR(labibb_reg->rdev)) {
+			dev_err(dev,
+				"qcom_labibb: error registering %s : %d\n",
+				child->full_name, ret);
+			return PTR_ERR(labibb_reg->rdev);
+		}
+	}
+
+	return 0;
+}
+
+static struct platform_driver qcom_labibb_regulator_driver = {
+	.driver	= {
+		.name = "qcom-lab-ibb-regulator",
+		.of_match_table	= qcom_labibb_match,
+	},
+	.probe = qcom_labibb_regulator_probe,
+};
+module_platform_driver(qcom_labibb_regulator_driver);
+
+MODULE_DESCRIPTION("Qualcomm labibb driver");
+MODULE_LICENSE("GPL v2");
-- 
2.26.2


^ permalink raw reply related

* [PATCH v3 5/6] bus: cdmm: Add MIPS R5 arch support
From: Serge Semin @ 2020-06-02 10:09 UTC (permalink / raw)
  To: Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman
  Cc: Serge Semin, Serge Semin, Alexey Malahov, Paul Burton,
	Rob Herring, Arnd Bergmann, Jason Cooper, Marc Zyngier,
	Rafael J. Wysocki, Daniel Lezcano, James Hogan, linux-mips,
	devicetree, linux-kernel
In-Reply-To: <20200602100921.1155-1-Sergey.Semin@baikalelectronics.ru>

CDMM may be available not only on MIPS R2 architectures, but also on
newer MIPS R5 chips. For instance our P5600 chip has one. Let's mark
the CDMM bus being supported for that MIPS arch too.

Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
 drivers/bus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 6d4e4497b59b..971c07bc92d4 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -58,7 +58,7 @@ config IMX_WEIM
 
 config MIPS_CDMM
 	bool "MIPS Common Device Memory Map (CDMM) Driver"
-	depends on CPU_MIPSR2
+	depends on CPU_MIPSR2 || CPU_MIPSR5
 	help
 	  Driver needed for the MIPS Common Device Memory Map bus in MIPS
 	  cores. This bus is for per-CPU tightly coupled devices such as the
-- 
2.26.2


^ permalink raw reply related

* [PATCH v4 1/5] regulator: Allow regulators to verify enabled during enable()
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
  To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
  Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
	rnayak, Sumit Semwal
In-Reply-To: <20200602100924.26256-1-sumit.semwal@linaro.org>

Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.

This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.

Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
--
v2: Address review comments, including swapping enable_time and poll_enabled_time.
---
 drivers/regulator/core.c         | 58 +++++++++++++++++++++++++++++++-
 include/linux/regulator/driver.h |  5 +++
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7486f6e4e613..d9ab888da95f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2347,6 +2347,32 @@ static void _regulator_enable_delay(unsigned int delay)
 		udelay(us);
 }
 
+/* _regulator_check_status_enabled
+ *
+ * returns:
+ *          1 if status shows regulator is in enabled state
+ *          0 if not enabled state
+ *          else, error value as received from ops->get_status()
+ */
+static inline int _regulator_check_status_enabled(struct regulator_dev *rdev)
+{
+	int ret = rdev->desc->ops->get_status(rdev);
+
+	if (ret < 0) {
+		rdev_info(rdev, "get_status returned error: %d\n", ret);
+		return ret;
+	}
+
+	switch (ret) {
+	case REGULATOR_STATUS_OFF:
+	case REGULATOR_STATUS_ERROR:
+	case REGULATOR_STATUS_UNDEFINED:
+		return 0;
+	default:
+		return 1;
+	}
+}
+
 static int _regulator_do_enable(struct regulator_dev *rdev)
 {
 	int ret, delay;
@@ -2407,7 +2433,37 @@ static int _regulator_do_enable(struct regulator_dev *rdev)
 	 * together.  */
 	trace_regulator_enable_delay(rdev_get_name(rdev));
 
-	_regulator_enable_delay(delay);
+	/* If poll_enabled_time is set, poll upto the delay calculated
+	 * above, delaying poll_enabled_time uS to check if the regulator
+	 * actually got enabled.
+	 * If the regulator isn't enabled after enable_delay has
+	 * expired, return -ETIMEDOUT.
+	 */
+	if (rdev->desc->poll_enabled_time) {
+		unsigned int time_remaining = delay;
+
+		while (time_remaining > 0) {
+			_regulator_enable_delay(rdev->desc->poll_enabled_time);
+
+			if (rdev->desc->ops->get_status) {
+				ret = _regulator_check_status_enabled(rdev);
+				if (ret < 0)
+					return ret;
+				else if (ret)
+					break;
+			} else if (rdev->desc->ops->is_enabled(rdev))
+				break;
+
+			time_remaining -= rdev->desc->poll_enabled_time;
+		}
+
+		if (time_remaining <= 0) {
+			rdev_err(rdev, "Enabled check failed.\n");
+			return -ETIMEDOUT;
+		}
+	} else {
+		_regulator_enable_delay(delay);
+	}
 
 	trace_regulator_enable_complete(rdev_get_name(rdev));
 
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 29d920516e0b..bb50e943010f 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -322,6 +322,9 @@ enum regulator_type {
  * @enable_time: Time taken for initial enable of regulator (in uS).
  * @off_on_delay: guard time (in uS), before re-enabling a regulator
  *
+ * @poll_enabled_time: Maximum time (in uS) to poll if the regulator is
+ *                          actually enabled, after enable() call
+ *
  * @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard mode
  */
 struct regulator_desc {
@@ -389,6 +392,8 @@ struct regulator_desc {
 
 	unsigned int off_on_delay;
 
+	unsigned int poll_enabled_time;
+
 	unsigned int (*of_map_mode)(unsigned int mode);
 };
 
-- 
2.26.2


^ permalink raw reply related

* [PATCH v4 0/5] Qualcomm labibb regulator driver
From: Sumit Semwal @ 2020-06-02 10:09 UTC (permalink / raw)
  To: agross, bjorn.andersson, lgirdwood, broonie, robh+dt
  Cc: nishakumari, linux-arm-msm, linux-kernel, devicetree, kgunda,
	rnayak, Sumit Semwal

This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs.
These regulators provide positive and/or negative boost power supplies
for LCD/LED display panels connected to the SoC.

This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs.

Changes from v3:
- Handled review comments from v3
- In core, swapped the meaning of enable_time and poll_enabled_time; so we
   wait for total enable_time delay, and poll in-between at poll_enabled_time
   interval now.
- fixed dt_bindings_check issues in dt-bindings patch.
- Cleanup of register_labibb_regulator(), and adapted to updated meaning of
   poll_enabled_time.

Changes from v2:
- Review comments from v2
- Moved the poll-to-check-enabled functionality to regulator core.
- Used more core features to simplify enable/disable functions.
- Moved the devicetree binding to yaml.
- Updated interrupt-names and simplified handling.

Changes from v1:
- Incorporated review comments from v1
- Changed from virtual-regulator based handling to individual regulator based
  handling.
- Reworked the core to merge most of enable/disable functions, combine the
  regulator_ops into one and allow for future variations.
- is_enabled() is now _really_ is_enabled()
- Simplified the SC interrupt handling - use regmap_read_poll_timeout,
  REGULATOR_EVENT_OVER_CURRENT handling and notification to clients.

Nisha Kumari (4):
  dt-bindings: regulator: Add labibb regulator
  arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
  regulator: qcom: Add labibb driver
  regulator: qcom: labibb: Add SC interrupt handling

Sumit Semwal (1):
  regulator: Allow regulators to verify enabled during enable()

 .../regulator/qcom-labibb-regulator.yaml      |  79 +++++
 arch/arm64/boot/dts/qcom/pmi8998.dtsi         |  14 +
 drivers/regulator/Kconfig                     |  10 +
 drivers/regulator/Makefile                    |   1 +
 drivers/regulator/core.c                      |  58 +++-
 drivers/regulator/qcom-labibb-regulator.c     | 289 ++++++++++++++++++
 include/linux/regulator/driver.h              |   5 +
 7 files changed, 455 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
 create mode 100644 drivers/regulator/qcom-labibb-regulator.c

-- 
2.26.2


^ permalink raw reply

* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-06-02  9:56 UTC (permalink / raw)
  To: Dongchun Zhu
  Cc: Tomasz Figa, Rob Herring, Linus Walleij, Bartosz Golaszewski,
	Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
	Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
	Linux Media Mailing List, linux-devicetree, Louis Kuo,
	Shengnan Wang (王圣男)
In-Reply-To: <1591078501.8804.539.camel@mhfsdcap03>

Hi Dongchun,

On Tue, Jun 02, 2020 at 02:15:01PM +0800, Dongchun Zhu wrote:
> Hi Tomasz, Sakari,
> 
> On Mon, 2020-06-01 at 20:18 +0200, Tomasz Figa wrote:
> > On Mon, Jun 1, 2020 at 4:35 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > On Fri, 2020-05-29 at 15:43 +0200, Tomasz Figa wrote:
> > > > On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> > > > >
> > > > > Hi Sakari,
> > > > >
> > > > > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > > > > Hi Dongchun,
> > > > > >
> > > > > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > > > > Hi Sakari, Rob,
> > > > > > >
> > > > > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > > > > Hi Rob, Dongchun,
> > > > > > > >
> > > > > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > > > > +    properties:
> > > > > > > > > > > > +      endpoint:
> > > > > > > > > > > > +        type: object
> > > > > > > > > > > > +        additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +        properties:
> > > > > > > > > >
> > > > > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > > > > >
> > > > > > > > > Yes, if you are using it.
> > > > > > > >
> > > > > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > > > > lane and that it does not support lane reordering?
> > > > > > > >
> > > > > > >
> > > > > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > > > > communication links between components inside a mobile device.
> > > > > > > The data lane has full support for HS(uni-directional) and
> > > > > > > LP(bi-directional) data transfer mode.'
> > > > > > >
> > > > > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > > > > would not be added in next release.
> > > > > > >
> > > > > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > > > > be removed IMO.
> > > > > > > >
> > > > > > >
> > > > > > > However, 'data-lanes' property may still be required.
> > > > > > > It is known that either data-lanes or clock-lanes is an array of
> > > > > > > physical data lane indexes. Position of an entry determines the logical
> > > > > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > > > > the clock lane is on hardware lane 0.
> > > > > > >
> > > > > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > > > > there is only a clock lane for OV02A10.
> > > > > > >
> > > > > > > Reminder:
> > > > > > > If 'data-lanes' property is not present, the driver would assume
> > > > > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > > > > property must be present and set to the right physical lane indexes.
> > > > > > > If the hardware does not support lane reordering, monotonically
> > > > > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > > > > whether or not there is also a clock lane.
> > > > > >
> > > > > > How can the driver use four lanes, considering the device only supports a
> > > > > > single lane??
> > > > > >
> > > > >
> > > > > I understood your meaning.
> > > > > If we omit the property 'data-lanes', the sensor should work still.
> > > > > But then what's the meaning of the existence of 'data-lanes'?
> > > > > If this property 'data-lanes' is always optional, then why dt-bindings
> > > > > provide the interface?
> > > > >
> > > > > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > > > > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > > > > shall enable four-lane configuration, which may increase consumption of
> > > > > both power and resource in the process of IIC communication.
> > > >
> > > > Wouldn't the receiver still have the data-lanes property under its
> > > > endpoint node, telling it how many lanes and in which order should be
> > > > used?
> > > >
> > >
> > > The MIPI receiver(RX) shall use
> > > v4l2_async_notifier_add_fwnode_remote_subdev() API to parse the property
> > > "data-lanes" under sensor output port.
> > 
> > That's not true. The MIPI receiver driver parses its own port node
> > corresponding to the sensor. Also quoting the documentation [1]:
> > 
> > "An endpoint subnode of a device contains all properties needed for
> > _configuration of this device_ for data exchange with other device. In most
> > cases properties at the peer 'endpoint' nodes will be identical, however they
> > might need to be different when there is any signal modifications on the bus
> > between two devices, e.g. there are logic signal inverters on the lines."
> > 
> > In this case, there is such a signal modification if the sensor has a
> > 1-lane bus and the receiver more lines, so the data-lanes properties
> > would be different on both sides.
> > 
> > [1] https://elixir.bootlin.com/linux/v5.7/source/Documentation/devicetree/bindings/media/video-interfaces.txt
> > 
> 
> Sorry for the misunderstanding.
> After doing some experiments about the data-lanes property under sensor
> i2c node, we found the API
> v4l2_async_notifier_add_fwnode_remote_subdev() that MIPI receiver driver
> used indeed parses the data-lanes under its own port node.
> 
> Sorry make a mistake for the use case of sensor data-lanes previously.
> Now We may encounter one new question for this patch.
> In practice we haven't used the data-lanes under sensor i2c node
> anywhere, if sensor driver itself doesn't parse that.
> 
> But there is still one reason to keep the exactly right data-lanes in
> DT. That is, the data-lanes under sensor i2c node could be used as a
> reference for MIPI receiver driver.
> Just as Tomasz said, 'The MIPI receiver driver parses its own port node
> corresponding to the sensor'.
> 
> Sakari, Tomasz, what's your opinions about the present of data-lanes
> under sensor node or not?

The receiver driver doesn't parse the properties in the sensor
(transmitter) device's endpoint. If that property provides no information
to the receiver, as is the case here, it should be omitted.

-- 
Regards,

Sakari Ailus

^ permalink raw reply

* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-06-02  9:53 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: Dongchun Zhu, Rob Herring, Linus Walleij, Bartosz Golaszewski,
	Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
	Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
	Linux Media Mailing List, linux-devicetree, Louis Kuo,
	Shengnan Wang (王圣男)
In-Reply-To: <CAAFQd5AuHDpQN8xZsWgnAt6m2reAYJbs9nBp0+mBo7_FS81LbQ@mail.gmail.com>

On Fri, May 29, 2020 at 03:43:30PM +0200, Tomasz Figa wrote:
> On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Sakari,
> >
> > On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > > Hi Dongchun,
> > >
> > > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > > Hi Sakari, Rob,
> > > >
> > > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > > Hi Rob, Dongchun,
> > > > >
> > > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > > +    properties:
> > > > > > > > > +      endpoint:
> > > > > > > > > +        type: object
> > > > > > > > > +        additionalProperties: false
> > > > > > > > > +
> > > > > > > > > +        properties:
> > > > > > >
> > > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > > >
> > > > > > Yes, if you are using it.
> > > > >
> > > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > > lane and that it does not support lane reordering?
> > > > >
> > > >
> > > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > > uni-directional clock lane and one bi-directional data lane solution for
> > > > communication links between components inside a mobile device.
> > > > The data lane has full support for HS(uni-directional) and
> > > > LP(bi-directional) data transfer mode.'
> > > >
> > > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > > would not be added in next release.
> > > >
> > > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > > be removed IMO.
> > > > >
> > > >
> > > > However, 'data-lanes' property may still be required.
> > > > It is known that either data-lanes or clock-lanes is an array of
> > > > physical data lane indexes. Position of an entry determines the logical
> > > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > > the clock lane is on hardware lane 0.
> > > >
> > > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > > there is only a clock lane for OV02A10.
> > > >
> > > > Reminder:
> > > > If 'data-lanes' property is not present, the driver would assume
> > > > four-lane operation. This means for one-lane or two-lane operation, this
> > > > property must be present and set to the right physical lane indexes.
> > > > If the hardware does not support lane reordering, monotonically
> > > > incremented values shall be used from 0 or 1 onwards, depending on
> > > > whether or not there is also a clock lane.
> > >
> > > How can the driver use four lanes, considering the device only supports a
> > > single lane??
> > >
> >
> > I understood your meaning.
> > If we omit the property 'data-lanes', the sensor should work still.
> > But then what's the meaning of the existence of 'data-lanes'?
> > If this property 'data-lanes' is always optional, then why dt-bindings
> > provide the interface?
> >
> > In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> > that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> > shall enable four-lane configuration, which may increase consumption of
> > both power and resource in the process of IIC communication.
> 
> Wouldn't the receiver still have the data-lanes property under its
> endpoint node, telling it how many lanes and in which order should be
> used?

Yes.

-- 
Sakari Ailus

^ permalink raw reply

* Re: [RFC PATCH -next] MAINTAINERS: Update F: and X: entry ordering (was Re: [PATCH v2 6/6] MAINTAINERS: Add maintainers for MIPS core drivers)
From: Serge Semin @ 2020-06-02  9:51 UTC (permalink / raw)
  To: Joe Perches
  Cc: Serge Semin, Andy Shevchenko, Andrew Morton, Linus Torvalds,
	Thomas Bogendoerfer, Thomas Gleixner, Greg Kroah-Hartman,
	Alexey Malahov, Paul Burton, Rob Herring, Arnd Bergmann,
	Jason Cooper, Marc Zyngier, Rafael J. Wysocki, Daniel Lezcano,
	James Hogan, linux-mips, devicetree, Linux Kernel Mailing List
In-Reply-To: <2e96576791604862a11f094665b0c4e9c3263fd4.camel@perches.com>

Hello Joe

On Mon, Jun 01, 2020 at 11:22:58AM -0700, Joe Perches wrote:
> On Mon, 2020-06-01 at 19:04 +0300, Andy Shevchenko wrote:
> > On Mon, Jun 1, 2020 at 6:52 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > On Mon, Jun 01, 2020 at 06:30:22PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Jun 1, 2020 at 6:19 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > > On Mon, Jun 01, 2020 at 04:56:21PM +0300, Andy Shevchenko wrote:
> > > > > > On Mon, Jun 1, 2020 at 3:26 PM Serge Semin <Sergey.Semin@baikalelectronics.ru> wrote:
> > > > > > > Add myself as a maintainer of MIPS CPU and GIC IRQchip, MIPS GIC timer
> > > > > > > and MIPS CPS CPUidle drivers.
> > > > > > ...
> > > > > > > +MIPS CORE DRIVERS
> > > > > > > +M:     Serge Semin <fancer.lancer@gmail.com>
> > > > > > > +L:     linux-mips@vger.kernel.org
> > > > > > > +S:     Supported
> > > > > > > +F:     drivers/bus/mips_cdmm.c
> > > > > > > +F:     drivers/irqchip/irq-mips-cpu.c
> > > > > > > +F:     drivers/irqchip/irq-mips-gic.c
> > > > > > > +F:     drivers/clocksource/mips-gic-timer.c
> > > > > > > +F:     drivers/cpuidle/cpuidle-cps.c
> > > > > > 
> > > > > > I think nowadays checkpatch.pl warns on wrong ordering in this data base.
> []
> > > Next time I won't forget that then. BTW the notes at the top of the MAINTAINERS
> > > file don't explicitly say about the files-list order. Only about the
> > > whole maintainers list entries order. Seeing the rest of the sub-entries like
> > > L:, M:, etc. aren't ordered then it's probably better to have an explicit
> > > statement, that files should be alphabetically listed, especially when
> > > checkpatch.pl starts warning about that.
> > 
> > Joe, what do you think?
> 
> Fine by me.  Maybe something like the below.
> 
> Another thing might be to intermix the F and X entries so that
> exclusions are more obviously against the F: entries.
> 
> There aren't many MAINTAINERS lines changed when the modified
> parse-maintainers is run, but I think it reads better.
> 
> It doesn't seem the last major reordering with parse-maintainers
> caused any significant issue for anyone.

I was also thinking about a text explaining the F: section order requirement.
Like this:

diff --git a/MAINTAINERS b/MAINTAINERS
index 865aeafee3b2..253f8f97891f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -111,7 +111,8 @@ Descriptions of section entries and preferred order
 	   F:	drivers/net/	all files in and below drivers/net
 	   F:	drivers/net/*	all files in drivers/net, but not below
 	   F:	*/net/*		all files in "any top level directory"/net
-	   One pattern per line.  Multiple F: lines acceptable.
+	   One pattern per line. Multiple F: lines acceptable, but are
+	   supposed to be listed in alphabetical order.
 	X: *Excluded* files and directories that are NOT maintained, same
 	   rules as F:. Files exclusions are tested before file matches.
 	   Can be useful for excluding a specific subdirectory, for instance:

The rest suggested by you is fine with me. Intermixing F and X seems reasonable
so the maintainers could group inclusion and exclusion sections together
with respect to the files/directories they refer to.

-Sergey

> 
> I think having Linus run scripts/parse-maintainers.pl just before
> every release or every few releases would make this issue go away.
> ---
>  MAINTAINERS                  |  1 +
>  scripts/checkpatch.pl        | 17 +++++++----------
>  scripts/parse-maintainers.pl |  5 ++---
>  3 files changed, 10 insertions(+), 13 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b045b70e54df..4b53119504ff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -118,6 +118,7 @@ Descriptions of section entries and preferred order
>  	   F:	net/
>  	   X:	net/ipv6/
>  	   matches all files in and below net excluding net/ipv6/
> +	   F: and X: entries are intermixed in case sensitive alphabetic order
>  	N: Files and directories *Regex* patterns.
>  	   N:	[^a-z]tegra	all files whose path contains tegra
>  	                        (not including files like integrator)
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index dd750241958b..499c85be0b2f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3099,16 +3099,13 @@ sub process {
>  				if ($curindex < 0) {
>  					WARN("MAINTAINERS_STYLE",
>  					     "Unknown MAINTAINERS entry type: '$cur'\n" . $herecurr);
> -				} else {
> -					if ($previndex >= 0 && $curindex < $previndex) {
> -						WARN("MAINTAINERS_STYLE",
> -						     "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
> -					} elsif ((($prev eq 'F' && $cur eq 'F') ||
> -						  ($prev eq 'X' && $cur eq 'X')) &&
> -						 ($prevval cmp $curval) > 0) {
> -						WARN("MAINTAINERS_STYLE",
> -						     "Misordered MAINTAINERS entry - list file patterns in alphabetic order\n" . $hereprev);
> -					}
> +				} elsif ($previndex >= 0 && $curindex < $previndex && !($prev =~ /[FX]/ && $cur =~ /[FX]/)) {
> +					WARN("MAINTAINERS_STYLE",
> +					     "Misordered MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev);
> +				} elsif ((($prev =~ /[FX]/ && $cur =~ /[FX]/) &&
> +					  ($prevval cmp $curval) > 0)) {
> +					WARN("MAINTAINERS_STYLE",
> +					     "Misordered MAINTAINERS entry - list F and X file patterns in alphabetic order\n" . $hereprev);
>  				}
>  			}
>  		}
> diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
> index 2ca4eb3f190d..8d2247a596f0 100755
> --- a/scripts/parse-maintainers.pl
> +++ b/scripts/parse-maintainers.pl
> @@ -84,9 +84,8 @@ sub by_pattern($$) {
>      $a_index = 1000 if ($a_index == -1);
>      $b_index = 1000 if ($b_index == -1);
>  
> -    if (($a1 =~ /^F$/ && $b1 =~ /^F$/) ||
> -	($a1 =~ /^X$/ && $b1 =~ /^X$/)) {
> -	return $a cmp $b;
> +    if (($a1 =~ /^[FX]$/ && $b1 =~ /^[FX]$/)) {
> +	return substr($a, 1) cmp substr($b, 1);
>      }
>  
>      if ($a_index < $b_index) {
> 
> 

^ permalink raw reply related

* Re: [PATCH 3/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property
From: Lars Povlsen @ 2020-06-02  9:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: Lars Povlsen, Sebastian Reichel, SoC Team, Alexandre Belloni,
	Microchip Linux Driver Support, linux-pm, devicetree,
	linux-kernel, linux-arm-kernel
In-Reply-To: <20200528022502.GA3234572@bogus>


Rob Herring writes:

> On Wed, May 13, 2020 at 03:08:40PM +0200, Lars Povlsen wrote:
>> This documents the 'microchip,reset-switch-core' property in the
>> ocelot-reset driver.
>>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>>  .../devicetree/bindings/power/reset/ocelot-reset.txt        | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> index 4d530d8154848..20fff03753ad2 100644
>> --- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> +++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
>> @@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
>>  Required Properties:
>>   - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
>>
>> +Optional properties:
>> +- microchip,reset-switch-core : Perform a switch core reset at the
>> +  time of driver load. This is may be used to initialize the switch
>> +  core to a known state (before other drivers are loaded).
>
> How do you know when other drivers are loaded? This could be a module
> perhaps. Doesn't seem like something that belongs in DT.
>

The reset driver is loaded at postcore_initcall() time, which ensures it
is loaded before other drivers using the switch core. I noticed other
drivers do the same to do low-level system reset and initialization at
early boot time.

> Can this behavior be implied with "microchip,sparx5-chip-reset"?

Since we need to cater for both modus operandi, I would need two driver
compatible strings per platform, which scales worse than a single
property.

The "microchip,reset-switch-core" is a device configuration property
which tells the system (driver) how the hw should be handled. Since you
do not *always* want to reset the switch core (f.ex. when implementing
systems with warm reboot), I think it makes perfect sense - but I may be
biased off course :-)

Thank you for (all) of your comments, by the way!

---Lars

>
> Rob

-- 
Lars Povlsen,
Microchip

^ permalink raw reply

* Re: [PATCH v7 21/24] iommu/arm-smmu-v3: Add stall support for platform devices
From: Jean-Philippe Brucker @ 2020-06-02  9:38 UTC (permalink / raw)
  To: Shameerali Kolothum Thodi
  Cc: iommu@lists.linux-foundation.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-mm@kvack.org, fenghua.yu@intel.com, kevin.tian@intel.com,
	jgg@ziepe.ca, catalin.marinas@arm.com, robin.murphy@arm.com,
	hch@infradead.org, zhangfei.gao@linaro.org,
	felix.kuehling@amd.com, will@kernel.org, christian.koenig@amd.com
In-Reply-To: <4741b6c45d1a43b69041ecb5ce0be0d5@huawei.com>

Hi Shameer,

On Mon, Jun 01, 2020 at 12:42:15PM +0000, Shameerali Kolothum Thodi wrote:
> >  /* IRQ and event handlers */
> > +static int arm_smmu_handle_evt(struct arm_smmu_device *smmu, u64 *evt)
> > +{
> > +	int ret;
> > +	u32 perm = 0;
> > +	struct arm_smmu_master *master;
> > +	bool ssid_valid = evt[0] & EVTQ_0_SSV;
> > +	u8 type = FIELD_GET(EVTQ_0_ID, evt[0]);
> > +	u32 sid = FIELD_GET(EVTQ_0_SID, evt[0]);
> > +	struct iommu_fault_event fault_evt = { };
> > +	struct iommu_fault *flt = &fault_evt.fault;
> > +
> > +	/* Stage-2 is always pinned at the moment */
> > +	if (evt[1] & EVTQ_1_S2)
> > +		return -EFAULT;
> > +
> > +	master = arm_smmu_find_master(smmu, sid);
> > +	if (!master)
> > +		return -EINVAL;
> > +
> > +	if (evt[1] & EVTQ_1_READ)
> > +		perm |= IOMMU_FAULT_PERM_READ;
> > +	else
> > +		perm |= IOMMU_FAULT_PERM_WRITE;
> > +
> > +	if (evt[1] & EVTQ_1_EXEC)
> > +		perm |= IOMMU_FAULT_PERM_EXEC;
> > +
> > +	if (evt[1] & EVTQ_1_PRIV)
> > +		perm |= IOMMU_FAULT_PERM_PRIV;
> > +
> > +	if (evt[1] & EVTQ_1_STALL) {
> > +		flt->type = IOMMU_FAULT_PAGE_REQ;
> > +		flt->prm = (struct iommu_fault_page_request) {
> > +			.flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> > +			.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]),
> > +			.grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
> > +			.perm = perm,
> > +			.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
> > +		};
> > +
> 
> > +		if (ssid_valid)
> > +			flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> 
> Do we need to set this for STALL mode only support? I had an issue with this
> being set on a vSVA POC based on our D06 zip device(which is a "fake " pci dev
> that supports STALL mode but no PRI). The issue is, CMDQ_OP_RESUME doesn't
> have any ssid or SSV params and works on sid and stag only.

I don't understand the problem, arm_smmu_page_response() doesn't set SSID
or SSV when sending a CMDQ_OP_RESUME. Could you detail the flow of a stall
event and RESUME command in your prototype?  Are you getting issues with
the host driver or the guest driver?

We do need to forward the SSV flag all the way to the guest driver, so the
guest can find the faulting address space using the SSID. Once the guest
handled the fault, then we don't send the SSID back to the host as part of
the RESUME command.

Thanks,
Jean

> Hence, it is difficult for
> Qemu SMMUv3 to populate this fields while preparing a page response. I can see
> that this flag is being checked in iopf_handle_single() (patch 04/24) as well. For POC,
> I used a temp fix[1] to work around this. Please let me know your thoughts.
> 
> Thanks,
> Shameer
> 
> 1. https://github.com/hisilicon/kernel-dev/commit/99ff96146e924055f38d97a5897e4becfa378d15
> 

^ permalink raw reply

* R: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: ansuelsmth @ 2020-06-02  9:34 UTC (permalink / raw)
  To: 'Rob Herring'
  Cc: 'Bjorn Andersson', 'Sham Muthayyan',
	'Andy Gross', 'Bjorn Helgaas',
	'Mark Rutland', 'Stanimir Varbanov',
	'Lorenzo Pieralisi', 'Andrew Murray',
	'Philipp Zabel', linux-arm-msm, linux-pci, devicetree,
	linux-kernel
In-Reply-To: <20200601210844.GA1494556@bogus>



> -----Messaggio originale-----
> Da: Rob Herring <robh@kernel.org>
> Inviato: lunedì 1 giugno 2020 23:09
> A: Ansuel Smith <ansuelsmth@gmail.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>; Sham Muthayyan
> <smuthayy@codeaurora.org>; Andy Gross <agross@kernel.org>; Bjorn
> Helgaas <bhelgaas@google.com>; Mark Rutland
> <mark.rutland@arm.com>; Stanimir Varbanov <svarbanov@mm-sol.com>;
> Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Murray
> <amurray@thegoodpenguin.co.uk>; Philipp Zabel
> <p.zabel@pengutronix.de>; linux-arm-msm@vger.kernel.org; linux-
> pci@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Oggetto: Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and
> set tx term offset
> 
> On Thu, May 14, 2020 at 10:07:09PM +0200, Ansuel Smith wrote:
> > Add tx term offset support to pcie qcom driver need in some revision of
> > the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2
> revision
> > and ipq8065 have the tx term offset set to 0.
> 
> Seems like this should be 2 patches or why isn't 'Ipq8064 have tx term
> offset set to 7' done in the prior patch? One tweak is needed for
> stable, but this isn't?
> 

Ok i will split this in 2 patch and set for stable the tx term patch.

> >
> > Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> >  drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> > index f5398b0d270c..ab6f1bdd24c3 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -45,6 +45,9 @@
> >  #define PCIE_CAP_CPL_TIMEOUT_DISABLE		0x10
> >
> >  #define PCIE20_PARF_PHY_CTRL			0x40
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK	GENMASK(20,
> 16)
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x)		((x) << 16)
> > +
> >  #define PCIE20_PARF_PHY_REFCLK			0x4C
> >  #define PHY_REFCLK_SSP_EN			BIT(16)
> >  #define PHY_REFCLK_USE_PAD			BIT(12)
> > @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> >  	val &= ~BIT(0);
> >  	writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> >
> > -	if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > +	if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
> > +	    of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> >  		writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> >  			       PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> >  			       PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> > @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> >  		writel(PHY_RX0_EQ(4), pcie->parf +
> PCIE20_PARF_CONFIG_BITS);
> >  	}
> >
> > +	if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > +		/* set TX termination offset */
> > +		val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> > +		val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> > +		val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> > +		writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> > +	}
> > +
> >  	/* enable external reference clock */
> >  	val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> > -	val |= BIT(16);
> > +	val &= ~PHY_REFCLK_USE_PAD;
> > +	val |= PHY_REFCLK_SSP_EN;
> >  	writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
> >
> >  	/* wait for clock acquisition */
> > @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct
> platform_device *pdev)
> >  static const struct of_device_id qcom_pcie_match[] = {
> >  	{ .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> >  	{ .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> > +	{ .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> >  	{ .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> >  	{ .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> >  	{ .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> > --
> > 2.25.1
> >


^ permalink raw reply

* R: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and set tx term offset
From: ansuelsmth @ 2020-06-02  9:31 UTC (permalink / raw)
  To: 'Stanimir Varbanov', 'Bjorn Andersson'
  Cc: 'Sham Muthayyan', 'Andy Gross',
	'Bjorn Helgaas', 'Rob Herring',
	'Mark Rutland', 'Lorenzo Pieralisi',
	'Andrew Murray', 'Philipp Zabel', linux-arm-msm,
	linux-pci, devicetree, linux-kernel
In-Reply-To: <e672c516-29a4-e7d2-ee8b-3bce73bdf4e2@mm-sol.com>



> -----Messaggio originale-----
> Da: Stanimir Varbanov <svarbanov@mm-sol.com>
> Inviato: martedì 2 giugno 2020 09:54
> A: Ansuel Smith <ansuelsmth@gmail.com>; Bjorn Andersson
> <bjorn.andersson@linaro.org>
> Cc: Sham Muthayyan <smuthayy@codeaurora.org>; Andy Gross
> <agross@kernel.org>; Bjorn Helgaas <bhelgaas@google.com>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Lorenzo
> Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Murray
> <amurray@thegoodpenguin.co.uk>; Philipp Zabel
> <p.zabel@pengutronix.de>; linux-arm-msm@vger.kernel.org; linux-
> pci@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Oggetto: Re: [PATCH v4 08/10] PCI: qcom: Add ipq8064 rev2 variant and
> set tx term offset
> 
> Hi,
> 
> On 5/14/20 11:07 PM, Ansuel Smith wrote:
> > Add tx term offset support to pcie qcom driver need in some revision of
> > the ipq806x SoC. Ipq8064 have tx term offset set to 7. Ipq8064-v2
> revision
> > and ipq8065 have the tx term offset set to 0.
> >
> > Signed-off-by: Sham Muthayyan <smuthayy@codeaurora.org>
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> >  drivers/pci/controller/dwc/pcie-qcom.c | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> > index f5398b0d270c..ab6f1bdd24c3 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -45,6 +45,9 @@
> >  #define PCIE_CAP_CPL_TIMEOUT_DISABLE		0x10
> >
> >  #define PCIE20_PARF_PHY_CTRL			0x40
> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK	GENMASK(20,
> 16)
> 
> I see you changed the mask, did you found the issue in previous v3 mask
> and shift?
> 

I checked the original code and the old GENMASK declaration was wrong as you
suggested.

> > +#define PHY_CTRL_PHY_TX0_TERM_OFFSET(x)		((x) << 16)
> > +
> >  #define PCIE20_PARF_PHY_REFCLK			0x4C
> >  #define PHY_REFCLK_SSP_EN			BIT(16)
> >  #define PHY_REFCLK_USE_PAD			BIT(12)
> > @@ -363,7 +366,8 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> >  	val &= ~BIT(0);
> >  	writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> >
> > -	if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > +	if (of_device_is_compatible(node, "qcom,pcie-ipq8064") |
> 
> this should be logical OR
> 

Will change in v5 since I will have to split this

> > +	    of_device_is_compatible(node, "qcom,pcie-ipq8064-v2")) {
> >  		writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> >  			       PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> >  			       PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> > @@ -374,9 +378,18 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> >  		writel(PHY_RX0_EQ(4), pcie->parf +
> PCIE20_PARF_CONFIG_BITS);
> >  	}
> >
> > +	if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> > +		/* set TX termination offset */
> > +		val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
> > +		val &= ~PHY_CTRL_PHY_TX0_TERM_OFFSET_MASK;
> > +		val |= PHY_CTRL_PHY_TX0_TERM_OFFSET(7);
> > +		writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
> > +	}
> > +
> >  	/* enable external reference clock */
> >  	val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
> > -	val |= BIT(16);
> > +	val &= ~PHY_REFCLK_USE_PAD;
> > +	val |= PHY_REFCLK_SSP_EN;
> >  	writel(val, pcie->parf + PCIE20_PARF_PHY_REFCLK);
> >
> >  	/* wait for clock acquisition */
> > @@ -1452,6 +1465,7 @@ static int qcom_pcie_probe(struct
> platform_device *pdev)
> >  static const struct of_device_id qcom_pcie_match[] = {
> >  	{ .compatible = "qcom,pcie-apq8084", .data = &ops_1_0_0 },
> >  	{ .compatible = "qcom,pcie-ipq8064", .data = &ops_2_1_0 },
> > +	{ .compatible = "qcom,pcie-ipq8064-v2", .data = &ops_2_1_0 },
> >  	{ .compatible = "qcom,pcie-apq8064", .data = &ops_2_1_0 },
> >  	{ .compatible = "qcom,pcie-msm8996", .data = &ops_2_3_2 },
> >  	{ .compatible = "qcom,pcie-ipq8074", .data = &ops_2_3_3 },
> >
> 
> --
> regards,
> Stan


^ permalink raw reply

* Re: [PATCH v5 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account
From: Serge Semin @ 2020-06-02  9:27 UTC (permalink / raw)
  To: Vinod Koul, Viresh Kumar
  Cc: Serge Semin, Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
	Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov, Alexey Kolotnikov,
	Thomas Bogendoerfer, Arnd Bergmann, Andy Shevchenko, Rob Herring,
	linux-mips, dmaengine, devicetree, linux-kernel
In-Reply-To: <20200529144054.4251-1-Sergey.Semin@baikalelectronics.ru>

Vinod, Viresh

Andy's finished his review. So all the patches of the series (except one rather
decorative, which we have different opinion of) are tagged by him. Since merge
window is about to be opened please consider to merge the series in. I'll really
need it to be in the kernel to provide the noLLP-problem fix for the Dw APB SSI
in 5.8.

-Sergey

On Fri, May 29, 2020 at 05:40:43PM +0300, Serge Semin wrote:
> Baikal-T1 SoC has an DW DMAC on-board to provide a Mem-to-Mem, low-speed
> peripherals Dev-to-Mem and Mem-to-Dev functionality. Mostly it's compatible
> with currently implemented in the kernel DW DMAC driver, but there are some
> peculiarities which must be taken into account in order to have the device
> fully supported.
> 
> First of all traditionally we replaced the legacy plain text-based dt-binding
> file with yaml-based one. Secondly Baikal-T1 DW DMA Controller provides eight
> channels, which alas have different max burst length configuration.
> In particular first two channels may burst up to 128 bits (16 bytes) at a time
> while the rest of them just up to 32 bits. We must make sure that the DMA
> subsystem doesn't set values exceeding these limitations otherwise the
> controller will hang up. In third currently we discovered the problem in using
> the DW APB SPI driver together with DW DMAC. The problem happens if there is no
> natively implemented multi-block LLP transfers support and the SPI-transfer
> length exceeds the max lock size. In this case due to asynchronous handling of
> Tx- and Rx- SPI transfers interrupt we might end up with Dw APB SSI Rx FIFO
> overflow. So if DW APB SSI (or any other DMAC service consumer) intends to use
> the DMAC to asynchronously execute the transfers we'd have to at least warn
> the user of the possible errors. In forth it's worth to set the DMA device max
> segment size with max block size config specific to the DW DMA controller. It
> shall help the DMA clients to create size-optimized SG-list items for the
> controller. This in turn will cause less dw_desc allocations, less LLP
> reinitializations, better DMA device performance.
> 
> Finally there is a bug in the algorithm of the nollp flag detection.
> In particular even if DW DMAC parameters state the multi-block transfers
> support there is still HC_LLP (hardcode LLP) flag, which if set makes expected
> by the driver true multi-block LLP functionality unusable. This happens cause'
> if HC_LLP flag is set the LLP registers will be hardcoded to zero so the
> contiguous multi-block transfers will be only supported. We must take the
> flag into account when detecting the LLP support otherwise the driver just
> won't work correctly.
> 
> This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> 0e698dfa2822 ("Linux 5.7-rc4")
> tag: v5.7-rc4
> 
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the properties. So do do with the
>   constraints in the DT binding.
> - Replace "additionalProperties: false" with "unevaluatedProperties: false"
>   property in the DT binding file.
> - Discard default settings defined out of property enum constraint.
> - Set default max-burst-len to 256 TR-WIDTH words in the DT binding.
> - Discard noLLP and block_size accessors.
> - Set max segment size of the DMA device structure with the DW DMA block size
>   config.
> - Print warning if noLLP flag is set.
> - Discard max burst length accessor.
> - Add comment about why hardware accelerated LLP list support depends
>   on both MBLK_EN and HC_LLP configs setting.
> - Use explicit bits state comparison operator in noLLP flag setting.
> 
> Link: https://lore.kernel.org/dmaengine/20200508105304.14065-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v3:
> - Use the block_size found for the very first channel instead of looking for
>   the maximum of maximum block sizes.
> - Don't define device-specific device_dma_parameters object, since it has
>   already been defined by the platform device core.
> - Add more details into the property description about what limitations
>   snps,max-burst-len defines.
> - Move commit fb7e3bbfc830 ("dmaengine: dw: Take HC_LLP flag into account for
>   noLLP auto-config") to the head of the series.
> - Add a new patch "dmaengine: Introduce min burst length capability" as a
>   result of the discussion with Vinod and Andy regarding the burst length
>   capability.
> - Add a new patch "dmaengine: Introduce max SG list entries capability"
>   suggested by Andy.
> - Add a new patch "dmaengine: Introduce DMA-device device_caps callback" as
>   a result of the discussion with Vinud and Andy in the framework of DW DMA
>   burst and LLP capabilities.
> - Add a new patch "dmaengine: dw: Add dummy device_caps callback" as a
>   preparation commit before setting the max_burst and max_sg_nents
>   DW DMA capabilities.
> - Override the slave channel max_burst capability instead of calculating
>   the minimum value of max burst lengths and setting the DMA-device
>   generic capability.
> - Add a new patch "dmaengine: dw: Initialize max_sg_nents with nollp flag".
>   This is required to fix the DW APB SSI issue of the Tx and Rx DMA
>   channels de-synchronization.
> 
> Link: https://lore.kernel.org/dmaengine/20200526225022.20405-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v4:
> - Use explicit if-else statement when assigning the max_sg_nents field.
> - Clamp the dst and src burst lengths in the generic dwc_config() method
>   instead of doing that in the encode_maxburst() callback.
> - Define max_burst with u32 type in struct dw_dma_platform_data.
> - Perform of_property_read_u32_array() with the platform data
>   max_burst member passed directly.
> - Add a new patch "dmaengine: dw: Initialize min_burst capability",
>   which initializes the min_burst capability with 1.
> - Fix of->if typo. It should be definitely "of" in the max_sg_list
>   capability description.
> 
> Link: https://lore.kernel.org/dmaengine/20200528222401.26941-1-Sergey.Semin@baikalelectronics.ru
> Changelog v5:
> - Introduce macro with extreme min and max burst lengths supported by the
>   DW DMA controller. Define them in the patch with default min and max burst
>   length iintializations.
> - Initialize max_burst length capability with extreme burst length supported
>   by the DW DMAC IP-core.
> - Move DW_DMA_MAX_BURST macro definition to the patch "dmaengine: dw:
>   Initialize min and max burst DMA device capability".
> - Add in-line comment at the point of the device_caps callback invocation.
> - Add doc-comment for the device_caps member of struct dma_device
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: dmaengine@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> Serge Semin (11):
>   dt-bindings: dma: dw: Convert DW DMAC to DT binding
>   dt-bindings: dma: dw: Add max burst transaction length property
>   dmaengine: Introduce min burst length capability
>   dmaengine: Introduce max SG list entries capability
>   dmaengine: Introduce DMA-device device_caps callback
>   dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config
>   dmaengine: dw: Set DMA device max segment size parameter
>   dmaengine: dw: Add dummy device_caps callback
>   dmaengine: dw: Initialize min and max burst DMA device capability
>   dmaengine: dw: Introduce max burst length hw config
>   dmaengine: dw: Initialize max_sg_nents capability
> 
>  .../bindings/dma/snps,dma-spear1340.yaml      | 176 ++++++++++++++++++
>  .../devicetree/bindings/dma/snps-dma.txt      |  69 -------
>  drivers/dma/dmaengine.c                       |  12 ++
>  drivers/dma/dw/core.c                         |  48 ++++-
>  drivers/dma/dw/of.c                           |   5 +
>  drivers/dma/dw/regs.h                         |   3 +
>  include/linux/dmaengine.h                     |  16 ++
>  include/linux/platform_data/dma-dw.h          |   5 +
>  8 files changed, 264 insertions(+), 70 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
>  delete mode 100644 Documentation/devicetree/bindings/dma/snps-dma.txt
> 
> -- 
> 2.26.2
> 

^ permalink raw reply

* Re: [PATCH 05/14] dt-bindings: arm: sparx5: Add documentation for Microchip Sparx5 SoC
From: Lars Povlsen @ 2020-06-02  9:10 UTC (permalink / raw)
  To: Rob Herring
  Cc: Lars Povlsen, SoC Team, Arnd Bergmann, Stephen Boyd,
	Linus Walleij, Steen Hegelund, Microchip Linux Driver Support,
	Olof Johansson, Michael Turquette, devicetree, linux-clk,
	linux-gpio, linux-arm-kernel, linux-kernel, Alexandre Belloni
In-Reply-To: <20200528021137.GA3214411@bogus>


Rob Herring writes:

> On Wed, May 13, 2020 at 02:55:23PM +0200, Lars Povlsen wrote:
>> This adds the main Sparx5 SoC DT documentation file, with information
>> abut the supported board types.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>>  .../bindings/arm/microchip,sparx5.yaml        | 87 +++++++++++++++++++
>>  1 file changed, 87 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> new file mode 100644
>> index 0000000000000..83b36d1217988
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> @@ -0,0 +1,87 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 Boards Device Tree Bindings
>> +
>> +maintainers:
>> +  - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |+
>> +   The Microchip Sparx5 SoC is a ARMv8-based used in a family of
>> +   gigabit TSN-capable gigabit switches.
>> +
>> +   The SparX-5 Ethernet switch family provides a rich set of switching
>> +   features such as advanced TCAM-based VLAN and QoS processing
>> +   enabling delivery of differentiated services, and security through
>> +   TCAM-based frame processing using versatile content aware processor
>> +   (VCAP)
>> +
>> +properties:
>> +  $nodename:
>> +    const: '/'
>> +  compatible:
>> +    oneOf:
>> +      - description: The Sparx5 pcb125 board is a modular board,
>> +          which has both spi-nor and eMMC storage. The modular design
>> +          allows for connection of different network ports.
>> +        items:
>> +          - const: microchip,sparx5-pcb125
>> +          - const: microchip,sparx5
>> +
>> +      - description: The Sparx5 pcb134 is a pizzabox form factor
>> +          gigabit switch with 20 SFP ports. It features spi-nor and
>> +          either spi-nand or eMMC storage (mount option).
>> +        items:
>> +          - const: microchip,sparx5-pcb134
>> +          - const: microchip,sparx5
>> +
>> +      - description: The Sparx5 pcb135 is a pizzabox form factor
>> +          gigabit switch with 48+4 Cu ports. It features spi-nor and
>> +          either spi-nand or eMMC storage (mount option).
>> +        items:
>> +          - const: microchip,sparx5-pcb135
>> +          - const: microchip,sparx5
>> +
>> +  axi@600000000:
>> +    type: object
>> +    description: the root node in the Sparx5 platforms must contain
>> +      an axi bus child node. They are always at physical address
>> +      0x600000000 in all the Sparx5 variants.
>> +    properties:
>> +      compatible:
>> +        items:
>> +          - const: simple-bus
>> +      reg:
>> +        maxItems: 1
>
> simple-bus doesn't have 'reg'. If there's bus registers, then it's not
> simple.
>

Ooops, that's a leftover. I'll remove.

>> +
>> +    required:
>> +      - compatible
>> +      - reg
>> +
>> +patternProperties:
>> +  "^syscon@[0-9a-f]+$":
>
> This should be under a bus node.

I thought it was? But anyway, with the change below I guess the entire
block goes away.

>
>> +    description: All Sparx5 boards must provide a system controller,
>> +      typically under the axi bus node. It contain reset registers and
>> +      other system control.
>> +    type: object
>> +    properties:
>> +      compatible:
>> +        items:
>> +          - const: microchip,sparx5-cpu-syscon
>> +          - const: syscon
>
> This probably should be in its own document. If really this simple,
> there's already syscon.yaml you can add to.

Good suggestion, I'll add it to mfd/syscon.yaml then.

>
>> +      reg:
>> +        maxItems: 1
>> +
>> +    required:
>> +      - compatible
>> +      - reg
>> +
>> +required:
>> +  - compatible
>> +  - axi@600000000
>> +  - syscon@600000000
>> +
>> +...
>> --
>> 2.26.2

--
Lars Povlsen,
Microchip

^ permalink raw reply

* Re: [PATCH v2 04/12] iio: imu: inv_icm42600: add gyroscope IIO device
From: Jean-Baptiste Maneyrol @ 2020-06-02  9:10 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: robh+dt@kernel.org, robh@kernel.org, mchehab+huawei@kernel.org,
	davem@davemloft.net, gregkh@linuxfoundation.org,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <20200531125415.6904a94d@archlinux>

Hi Jonathan,

for the calibration bias, value is expressed in g unit, fixed, independant from any scale value.
So I can switch to g instead of SI unit, but this will still not be like raw data which are dependent of the scale value. That's why I used SI units.

Another solution, would be to adapt the value depending on the scale setting. So that it will correspond to raw data. But this also invovles complex computation.

Tell me what you prefer.

Thanks,
JB

From: Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, May 31, 2020 13:54
To: Jean-Baptiste Maneyrol <JManeyrol@invensense.com>
Cc: robh+dt@kernel.org <robh+dt@kernel.org>; robh@kernel.org <robh@kernel.org>; mchehab+huawei@kernel.org <mchehab+huawei@kernel.org>; davem@davemloft.net <davem@davemloft.net>; gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; devicetree@vger.kernel.org <devicetree@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 04/12] iio: imu: inv_icm42600: add gyroscope IIO device 
 
 CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe.

On Wed, 27 May 2020 20:57:03 +0200
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> wrote:

> Add IIO device for gyroscope sensor with data polling interface.
> Attributes: raw, scale, sampling_frequency, calibbias.
> 
> Gyroscope in low noise mode.
> 
> Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>

Unusual to have a calibration offset specified in output units,
which contributes a lot of the complexity in here.
Normally those are strictly front end (output of some calibration DAC).
So if they have units (and often they don't) I'd expect them to be
the same as _raw.

We need to tidy up the docs on this though as it doesn't express
any sort of preference.  It's hard to be specific as often the calibration
scales are defined - they are just like tweaking a POT on an analog
sensor board.

A few trivial other things inline, including a suggestion to modify
the layering of the driver a tiny bit during probe.

Thanks,

Jonathan

> ---
>  drivers/iio/imu/inv_icm42600/inv_icm42600.h   |   6 +
>  .../iio/imu/inv_icm42600/inv_icm42600_core.c  |   4 +
>  .../iio/imu/inv_icm42600/inv_icm42600_gyro.c  | 600 ++++++++++++++++++
>  3 files changed, 610 insertions(+)
>  create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> 
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 14c8ef152418..c1023d59b37b 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -120,6 +120,8 @@ struct inv_icm42600_suspended {
>   *  @orientation:    sensor chip orientation relative to main hardware.
>   *  @conf:           chip sensors configurations.
>   *  @suspended:              suspended sensors configuration.
> + *  @indio_gyro:     gyroscope IIO device.
> + *  @buffer:         data transfer buffer aligned for DMA.
>   */
>  struct inv_icm42600_state {
>        struct mutex lock;
> @@ -131,6 +133,8 @@ struct inv_icm42600_state {
>        struct iio_mount_matrix orientation;
>        struct inv_icm42600_conf conf;
>        struct inv_icm42600_suspended suspended;
> +     struct iio_dev *indio_gyro;
> +     uint8_t buffer[2] ____cacheline_aligned;
>  };
>  
>  /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB */
> @@ -369,4 +373,6 @@ int inv_icm42600_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
>  int inv_icm42600_core_probe(struct regmap *regmap, int chip,
>                            inv_icm42600_bus_setup bus_setup);
>  
> +int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
> +
>  #endif
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> index 81b171d6782c..dccb7bcc782e 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> @@ -510,6 +510,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int chip,
>        if (ret)
>                return ret;
>  
> +     ret = inv_icm42600_gyro_init(st);
> +     if (ret)
> +             return ret;
> +
>        /* setup runtime power management */
>        ret = pm_runtime_set_active(dev);
>        if (ret)
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> new file mode 100644
> index 000000000000..9d9672989b23
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> @@ -0,0 +1,600 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Invensense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/delay.h>
> +#include <linux/math64.h>
> +#include <linux/iio/iio.h>
> +
> +#include "inv_icm42600.h"
> +
> +#define INV_ICM42600_GYRO_CHAN(_modifier, _index, _ext_info)         \
> +     {                                                               \
> +             .type = IIO_ANGL_VEL,                                   \
> +             .modified = 1,                                          \
> +             .channel2 = _modifier,                                  \
> +             .info_mask_separate =                                   \
> +                     BIT(IIO_CHAN_INFO_RAW) |                        \
> +                     BIT(IIO_CHAN_INFO_CALIBBIAS),                   \
> +             .info_mask_shared_by_type =                             \
> +                     BIT(IIO_CHAN_INFO_SCALE),                       \
> +             .info_mask_shared_by_type_available =                   \
> +                     BIT(IIO_CHAN_INFO_SCALE) |                      \
> +                     BIT(IIO_CHAN_INFO_CALIBBIAS),                   \
> +             .info_mask_shared_by_all =                              \
> +                     BIT(IIO_CHAN_INFO_SAMP_FREQ),                   \
> +             .info_mask_shared_by_all_available =                    \
> +                     BIT(IIO_CHAN_INFO_SAMP_FREQ),                   \
> +             .scan_index = _index,                                   \
> +             .scan_type = {                                          \
> +                     .sign = 's',                                    \
> +                     .realbits = 16,                                 \
> +                     .storagebits = 16,                              \
> +                     .endianness = IIO_BE,                           \
> +             },                                                      \
> +             .ext_info = _ext_info,                                  \
> +     }
> +
> +enum inv_icm42600_gyro_scan {
> +     INV_ICM42600_GYRO_SCAN_X,
> +     INV_ICM42600_GYRO_SCAN_Y,
> +     INV_ICM42600_GYRO_SCAN_Z,
> +};
> +
> +static const struct iio_chan_spec_ext_info inv_icm42600_gyro_ext_infos[] = {
> +     IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42600_get_mount_matrix),
> +     {},
> +};
> +
> +static const struct iio_chan_spec inv_icm42600_gyro_channels[] = {
> +     INV_ICM42600_GYRO_CHAN(IIO_MOD_X, INV_ICM42600_GYRO_SCAN_X,
> +                            inv_icm42600_gyro_ext_infos),
> +     INV_ICM42600_GYRO_CHAN(IIO_MOD_Y, INV_ICM42600_GYRO_SCAN_Y,
> +                            inv_icm42600_gyro_ext_infos),
> +     INV_ICM42600_GYRO_CHAN(IIO_MOD_Z, INV_ICM42600_GYRO_SCAN_Z,
> +                            inv_icm42600_gyro_ext_infos),
> +};
> +
> +static int inv_icm42600_gyro_read_sensor(struct inv_icm42600_state *st,
> +                                      struct iio_chan_spec const *chan,
> +                                      int16_t *val)
> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> +     unsigned int reg;
> +     __be16 *data;
> +     int ret;
> +
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (chan->channel2) {
> +     case IIO_MOD_X:
> +             reg = INV_ICM42600_REG_GYRO_DATA_X;
> +             break;
> +     case IIO_MOD_Y:
> +             reg = INV_ICM42600_REG_GYRO_DATA_Y;
> +             break;
> +     case IIO_MOD_Z:
> +             reg = INV_ICM42600_REG_GYRO_DATA_Z;
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +
> +     pm_runtime_get_sync(dev);
> +     mutex_lock(&st->lock);
> +
> +     /* enable gyro sensor */
> +     conf.mode = INV_ICM42600_SENSOR_MODE_LOW_NOISE;
> +     ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> +     if (ret)
> +             goto exit;
> +
> +     /* read gyro register data */
> +     data = (__be16 *)&st->buffer[0];
> +     ret = regmap_bulk_read(st->map, reg, data, sizeof(*data));
> +     if (ret)
> +             goto exit;
> +
> +     *val = (int16_t)be16_to_cpup(data);
> +     if (*val == INV_ICM42600_DATA_INVALID)
> +             ret = -EINVAL;
> +exit:
> +     mutex_unlock(&st->lock);
> +     pm_runtime_mark_last_busy(dev);
> +     pm_runtime_put_autosuspend(dev);
> +     return ret;
> +}
> +
> +/* IIO format int + nano */
> +static const int inv_icm42600_gyro_scale[] = {
> +     /* +/- 2000dps => 0.001065264 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_2000DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_2000DPS + 1] = 1065264,
> +     /* +/- 1000dps => 0.000532632 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_1000DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_1000DPS + 1] = 532632,
> +     /* +/- 500dps => 0.000266316 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_500DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_500DPS + 1] = 266316,
> +     /* +/- 250dps => 0.000133158 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_250DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_250DPS + 1] = 133158,
> +     /* +/- 125dps => 0.000066579 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_125DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_125DPS + 1] = 66579,
> +     /* +/- 62.5dps => 0.000033290 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_62_5DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_62_5DPS + 1] = 33290,
> +     /* +/- 31.25dps => 0.000016645 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_31_25DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_31_25DPS + 1] = 16645,
> +     /* +/- 15.625dps => 0.000008322 rad/s */
> +     [2 * INV_ICM42600_GYRO_FS_15_625DPS] = 0,
> +     [2 * INV_ICM42600_GYRO_FS_15_625DPS + 1] = 8322,
> +};
> +
> +static int inv_icm42600_gyro_read_scale(struct inv_icm42600_state *st,
> +                                     int *val, int *val2)
> +{
> +     unsigned int idx;
> +
> +     idx = st->conf.gyro.fs;
> +
> +     *val = inv_icm42600_gyro_scale[2 * idx];
> +     *val2 = inv_icm42600_gyro_scale[2 * idx + 1];
> +     return IIO_VAL_INT_PLUS_NANO;
> +}
> +
> +static int inv_icm42600_gyro_write_scale(struct inv_icm42600_state *st,
> +                                      int val, int val2)
> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     unsigned int idx;
> +     struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> +     int ret;
> +
> +     for (idx = 0; idx < ARRAY_SIZE(inv_icm42600_gyro_scale); idx += 2) {
> +             if (val == inv_icm42600_gyro_scale[idx] &&
> +                 val2 == inv_icm42600_gyro_scale[idx + 1])
> +                     break;
> +     }
> +     if (idx >= ARRAY_SIZE(inv_icm42600_gyro_scale))
> +             return -EINVAL;
> +
> +     conf.fs = idx / 2;
> +
> +     pm_runtime_get_sync(dev);
> +     mutex_lock(&st->lock);
> +
> +     ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> +
> +     mutex_unlock(&st->lock);
> +     pm_runtime_mark_last_busy(dev);
> +     pm_runtime_put_autosuspend(dev);
> +
> +     return ret;
> +}
> +
> +/* IIO format int + micro */
> +static const int inv_icm42600_gyro_odr[] = {
> +     /* 12.5Hz */
> +     12, 500000,
> +     /* 25Hz */
> +     25, 0,
> +     /* 50Hz */
> +     50, 0,
> +     /* 100Hz */
> +     100, 0,
> +     /* 200Hz */
> +     200, 0,
> +     /* 1kHz */
> +     1000, 0,
> +     /* 2kHz */
> +     2000, 0,
> +     /* 4kHz */
> +     4000, 0,
> +};
> +
> +static const int inv_icm42600_gyro_odr_conv[] = {
> +     INV_ICM42600_ODR_12_5HZ,
> +     INV_ICM42600_ODR_25HZ,
> +     INV_ICM42600_ODR_50HZ,
> +     INV_ICM42600_ODR_100HZ,
> +     INV_ICM42600_ODR_200HZ,
> +     INV_ICM42600_ODR_1KHZ_LN,
> +     INV_ICM42600_ODR_2KHZ_LN,
> +     INV_ICM42600_ODR_4KHZ_LN,
> +};
> +
> +static int inv_icm42600_gyro_read_odr(struct inv_icm42600_state *st,
> +                                   int *val, int *val2)
> +{
> +     unsigned int odr;
> +     unsigned int i;
> +
> +     odr = st->conf.gyro.odr;
> +
> +     for (i = 0; i < ARRAY_SIZE(inv_icm42600_gyro_odr_conv); ++i) {
> +             if (inv_icm42600_gyro_odr_conv[i] == odr)
> +                     break;
> +     }
> +     if (i >= ARRAY_SIZE(inv_icm42600_gyro_odr_conv))
> +             return -EINVAL;
> +
> +     *val = inv_icm42600_gyro_odr[2 * i];
> +     *val2 = inv_icm42600_gyro_odr[2 * i + 1];
> +
> +     return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42600_gyro_write_odr(struct inv_icm42600_state *st,
> +                                    int val, int val2)
> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     unsigned int idx;
> +     struct inv_icm42600_sensor_conf conf = INV_ICM42600_SENSOR_CONF_INIT;
> +     int ret;
> +
> +     for (idx = 0; idx < ARRAY_SIZE(inv_icm42600_gyro_odr); idx += 2) {
> +             if (val == inv_icm42600_gyro_odr[idx] &&
> +                 val2 == inv_icm42600_gyro_odr[idx + 1])
> +                     break;
> +     }
> +     if (idx >= ARRAY_SIZE(inv_icm42600_gyro_odr))
> +             return -EINVAL;
> +
> +     conf.odr = inv_icm42600_gyro_odr_conv[idx / 2];
> +
> +     pm_runtime_get_sync(dev);
> +     mutex_lock(&st->lock);
> +
> +     ret = inv_icm42600_set_gyro_conf(st, &conf, NULL);
> +
> +     mutex_unlock(&st->lock);
> +     pm_runtime_mark_last_busy(dev);
> +     pm_runtime_put_autosuspend(dev);
> +
> +     return ret;
> +}
> +
> +/*
> + * Calibration bias values, IIO range format int + nano.
> + * Value is limited to +/-64dps coded on 12 bits signed. Step is 1/32 dps.
> + */
> +static int inv_icm42600_gyro_calibbias[] = {
> +     -1, 117010721,          /* min: -1.117010721 rad/s */
> +     0, 545415,              /* step: 0.000545415 rad/s */
> +     1, 116465306,           /* max: 1.116465306 rad/s */
> +};
> +
> +static int inv_icm42600_gyro_read_offset(struct inv_icm42600_state *st,
> +                                      struct iio_chan_spec const *chan,
> +                                      int *val, int *val2)
> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     int64_t val64;
> +     int32_t bias;
> +     unsigned int reg;
> +     int16_t offset;
> +     uint8_t data[2];
> +     int ret;
> +
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (chan->channel2) {
> +     case IIO_MOD_X:
> +             reg = INV_ICM42600_REG_OFFSET_USER0;
> +             break;
> +     case IIO_MOD_Y:
> +             reg = INV_ICM42600_REG_OFFSET_USER1;
> +             break;
> +     case IIO_MOD_Z:
> +             reg = INV_ICM42600_REG_OFFSET_USER3;
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +
> +     pm_runtime_get_sync(dev);
> +     mutex_lock(&st->lock);
> +
> +     ret = regmap_bulk_read(st->map, reg, st->buffer, sizeof(data));
> +     memcpy(data, st->buffer, sizeof(data));
> +
> +     mutex_unlock(&st->lock);
> +     pm_runtime_mark_last_busy(dev);
> +     pm_runtime_put_autosuspend(dev);
> +     if (ret)
> +             return ret;
> +
> +     /* 12 bits signed value */
> +     switch (chan->channel2) {
> +     case IIO_MOD_X:
> +             offset = sign_extend32(((data[1] & 0x0F) << 8) | data[0], 11);
> +             break;
> +     case IIO_MOD_Y:
> +             offset = sign_extend32(((data[0] & 0xF0) << 4) | data[1], 11);
> +             break;
> +     case IIO_MOD_Z:
> +             offset = sign_extend32(((data[1] & 0x0F) << 8) | data[0], 11);
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +
> +     /*
> +      * convert raw offset to dps then to rad/s
> +      * 12 bits signed raw max 64 to dps: 64 / 2048
> +      * dps to rad: Pi / 180
> +      * result in nano (1000000000)
> +      * (offset * 64 * Pi * 1000000000) / (2048 * 180)
> +      */
> +     val64 = (int64_t)offset * 64LL * 3141592653LL;
> +     /* for rounding, add + or - divisor (2048 * 180) divided by 2 */
> +     if (val64 >= 0)
> +             val64 += 2048 * 180 / 2;
> +     else
> +             val64 -= 2048 * 180 / 2;
> +     bias = div_s64(val64, 2048 * 180);
> +     *val = bias / 1000000000L;
> +     *val2 = bias % 1000000000L;
> +
> +     return IIO_VAL_INT_PLUS_NANO;
> +}
> +
> +static int inv_icm42600_gyro_write_offset(struct inv_icm42600_state *st,
> +                                       struct iio_chan_spec const *chan,
> +                                       int val, int val2)
> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     int64_t val64, min, max;
> +     unsigned int reg, regval;
> +     int16_t offset;
> +     int ret;
> +
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (chan->channel2) {
> +     case IIO_MOD_X:
> +             reg = INV_ICM42600_REG_OFFSET_USER0;
> +             break;
> +     case IIO_MOD_Y:
> +             reg = INV_ICM42600_REG_OFFSET_USER1;
> +             break;
> +     case IIO_MOD_Z:
> +             reg = INV_ICM42600_REG_OFFSET_USER3;
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +
> +     /* inv_icm42600_gyro_calibbias: min - step - max in nano */
> +     min = (int64_t)inv_icm42600_gyro_calibbias[0] * 1000000000LL +
> +           (int64_t)inv_icm42600_gyro_calibbias[1];
> +     max = (int64_t)inv_icm42600_gyro_calibbias[4] * 1000000000LL +
> +           (int64_t)inv_icm42600_gyro_calibbias[5];
> +     val64 = (int64_t)val * 1000000000LL + (int64_t)val2;
> +     if (val64 < min || val64 > max)
> +             return -EINVAL;
> +
> +     /*
> +      * convert rad/s to dps then to raw value
> +      * rad to dps: 180 / Pi
> +      * dps to raw 12 bits signed, max 64: 2048 / 64
> +      * val in nano (1000000000)
> +      * val * 180 * 2048 / (Pi * 1000000000 * 64)
> +      */
> +     val64 = val64 * 180LL * 2048LL;
> +     /* for rounding, add + or - divisor (3141592653 * 64) divided by 2 */
> +     if (val64 >= 0)
> +             val64 += 3141592653LL * 64LL / 2LL;
> +     else
> +             val64 -= 3141592653LL * 64LL / 2LL;
> +     offset = div64_s64(val64, 3141592653LL * 64LL);
> +
> +     /* clamp value limited to 12 bits signed */
> +     if (offset < -2048)
> +             offset = -2048;
> +     else if (offset > 2047)
> +             offset = 2047;
> +
> +     pm_runtime_get_sync(dev);
> +     mutex_lock(&st->lock);
> +
> +     switch (chan->channel2) {
> +     case IIO_MOD_X:
> +             /* OFFSET_USER1 register is shared */
> +             ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER1,
> +                               &regval);
> +             if (ret)
> +                     goto out_unlock;
> +             st->buffer[0] = offset & 0xFF;
> +             st->buffer[1] = (regval & 0xF0) | ((offset & 0xF00) >> 8);
> +             break;
> +     case IIO_MOD_Y:
> +             /* OFFSET_USER1 register is shared */
> +             ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER1,
> +                               &regval);
> +             if (ret)
> +                     goto out_unlock;
> +             st->buffer[0] = ((offset & 0xF00) >> 4) | (regval & 0x0F);
> +             st->buffer[1] = offset & 0xFF;
> +             break;
> +     case IIO_MOD_Z:
> +             /* OFFSET_USER4 register is shared */
> +             ret = regmap_read(st->map, INV_ICM42600_REG_OFFSET_USER4,
> +                               &regval);
> +             if (ret)
> +                     goto out_unlock;
> +             st->buffer[0] = offset & 0xFF;
> +             st->buffer[1] = (regval & 0xF0) | ((offset & 0xF00) >> 8);
> +             break;
> +     default:
> +             ret = -EINVAL;
> +             goto out_unlock;
> +     }
> +
> +     ret = regmap_bulk_write(st->map, reg, st->buffer, 2);
> +
> +out_unlock:
> +     mutex_unlock(&st->lock);
> +     pm_runtime_mark_last_busy(dev);
> +     pm_runtime_put_autosuspend(dev);
> +     return ret;
> +}
> +
> +static int inv_icm42600_gyro_read_raw(struct iio_dev *indio_dev,
> +                                   struct iio_chan_spec const *chan,
> +                                   int *val, int *val2, long mask)
> +{
> +     struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev);
> +     int16_t data;
> +     int ret;
> +
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (mask) {
> +     case IIO_CHAN_INFO_RAW:
> +             ret = iio_device_claim_direct_mode(indio_dev);
> +             if (ret)
> +                     return ret;
> +             ret = inv_icm42600_gyro_read_sensor(st, chan, &data);
> +             iio_device_release_direct_mode(indio_dev);
> +             if (ret)
> +                     return ret;
> +             *val = data;
> +             return IIO_VAL_INT;
> +     case IIO_CHAN_INFO_SCALE:
> +             return inv_icm42600_gyro_read_scale(st, val, val2);
> +     case IIO_CHAN_INFO_SAMP_FREQ:
> +             return inv_icm42600_gyro_read_odr(st, val, val2);
> +     case IIO_CHAN_INFO_CALIBBIAS:
> +             return inv_icm42600_gyro_read_offset(st, chan, val, val2);
> +     default:
> +             return -EINVAL;
> +     }
> +}
> +
> +static int inv_icm42600_gyro_read_avail(struct iio_dev *indio_dev,
> +                                     struct iio_chan_spec const *chan,
> +                                     const int **vals,
> +                                     int *type, int *length, long mask)
> +{
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (mask) {
> +     case IIO_CHAN_INFO_SCALE:
> +             *vals = inv_icm42600_gyro_scale;
> +             *type = IIO_VAL_INT_PLUS_NANO;
> +             *length = ARRAY_SIZE(inv_icm42600_gyro_scale);
> +             return IIO_AVAIL_LIST;
> +     case IIO_CHAN_INFO_SAMP_FREQ:
> +             *vals = inv_icm42600_gyro_odr;
> +             *type = IIO_VAL_INT_PLUS_MICRO;
> +             *length = ARRAY_SIZE(inv_icm42600_gyro_odr);
> +             return IIO_AVAIL_LIST;
> +     case IIO_CHAN_INFO_CALIBBIAS:
> +             *vals = inv_icm42600_gyro_calibbias;
> +             *type = IIO_VAL_INT_PLUS_NANO;
> +             return IIO_AVAIL_RANGE;
> +     default:
> +             return -EINVAL;
> +     }
> +}
> +
> +static int inv_icm42600_gyro_write_raw(struct iio_dev *indio_dev,
> +                                    struct iio_chan_spec const *chan,
> +                                    int val, int val2, long mask)
> +{
> +     struct inv_icm42600_state *st = iio_device_get_drvdata(indio_dev);
> +     int ret;
> +
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (mask) {
> +     case IIO_CHAN_INFO_SCALE:
> +             ret = iio_device_claim_direct_mode(indio_dev);
> +             if (ret)
> +                     return ret;
> +             ret = inv_icm42600_gyro_write_scale(st, val, val2);
> +             iio_device_release_direct_mode(indio_dev);
> +             return ret;
> +     case IIO_CHAN_INFO_SAMP_FREQ:
> +             return inv_icm42600_gyro_write_odr(st, val, val2);
> +     case IIO_CHAN_INFO_CALIBBIAS:
> +             ret = iio_device_claim_direct_mode(indio_dev);
> +             if (ret)
> +                     return ret;
> +             ret = inv_icm42600_gyro_write_offset(st, chan, val, val2);
> +             iio_device_release_direct_mode(indio_dev);
> +             return ret;
> +     default:
> +             return -EINVAL;
> +     }
> +}
> +
> +static int inv_icm42600_gyro_write_raw_get_fmt(struct iio_dev *indio_dev,
> +                                            struct iio_chan_spec const *chan,
> +                                            long mask)
> +{
> +     if (chan->type != IIO_ANGL_VEL)
> +             return -EINVAL;
> +
> +     switch (mask) {
> +     case IIO_CHAN_INFO_SCALE:
> +             return IIO_VAL_INT_PLUS_NANO;
> +     case IIO_CHAN_INFO_SAMP_FREQ:
> +             return IIO_VAL_INT_PLUS_MICRO;
> +     case IIO_CHAN_INFO_CALIBBIAS:
> +             return IIO_VAL_INT_PLUS_NANO;
> +     default:
> +             return -EINVAL;
> +     }
> +}
> +
> +static const struct iio_info inv_icm42600_gyro_info = {
> +     .read_raw = inv_icm42600_gyro_read_raw,
> +     .read_avail = inv_icm42600_gyro_read_avail,
> +     .write_raw = inv_icm42600_gyro_write_raw,
> +     .write_raw_get_fmt = inv_icm42600_gyro_write_raw_get_fmt,
> +     .debugfs_reg_access = inv_icm42600_debugfs_reg,
> +};
> +
> +int inv_icm42600_gyro_init(struct inv_icm42600_state *st)

This feels like the layering would be clearer if this
returned the struct iio_dev * and the assignment happened in the
core driver.

Then state parameter can be const and it'll be obvious it has
no side effects on the state structure.

> +{
> +     struct device *dev = regmap_get_device(st->map);
> +     const char *name;
> +     struct iio_dev *indio_dev;
> +
> +     name = devm_kasprintf(dev, GFP_KERNEL, "%s-gyro", st->name);
> +     if (!name)
> +             return -ENOMEM;
> +
> +     indio_dev = devm_iio_device_alloc(dev, 0);
> +     if (!indio_dev)
> +             return -ENOMEM;
> +
> +     iio_device_set_drvdata(indio_dev, st);
> +     indio_dev->dev.parent = dev;
> +     indio_dev->name = name;
> +     indio_dev->info = &inv_icm42600_gyro_info;
> +     indio_dev->modes = INDIO_DIRECT_MODE;
> +     indio_dev->channels = inv_icm42600_gyro_channels;
> +     indio_dev->num_channels = ARRAY_SIZE(inv_icm42600_gyro_channels);
> +
> +     st->indio_gyro = indio_dev;
> +     return devm_iio_device_register(dev, st->indio_gyro);
> +}

^ permalink raw reply

* Re: [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-02  9:07 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
	Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
	linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <20200601214302.GA1538223@bogus>

Hi Rob,

On 2020/06/02 6:43, Rob Herring wrote:
> On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
>> Even if phy driver doesn't probe, the error message can't be distinguished
>> from other errors. This displays error message caused by the phy driver
>> explicitly.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
>>   1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
>> index 493f105..7ae9688 100644
>> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
>> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
>> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
>>   		return PTR_ERR(priv->rst);
>>   
>>   	priv->phy = devm_phy_optional_get(dev, "pcie-phy");
>> -	if (IS_ERR(priv->phy))
>> -		return PTR_ERR(priv->phy);
>> +	if (IS_ERR(priv->phy)) {
>> +		ret = PTR_ERR(priv->phy);
>> +		dev_err(dev, "Failed to get phy (%d)\n", ret);
> 
> This will print an error on EPROBE_DEFERRED which isn't an error.

Thanks for pointing out.
Surely this message should be suppressed when returning EPROBE_DEFERRED.

Thank you,
  
---
Best Regards
Kunihiko Hayashi

^ permalink raw reply

* Re: [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-06-02  9:07 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
	Masahiro Yamada, linux-pci, devicetree, linux-arm-kernel,
	linux-kernel, Masami Hiramatsu, Jassi Brar
In-Reply-To: <20200601213215.GA1521885@bogus>

Hi Rob,

On 2020/06/02 6:32, Rob Herring wrote:
> On Fri, May 15, 2020 at 06:59:02PM +0900, Kunihiko Hayashi wrote:
>> This gets iATU register area from reg property. In Synopsis DWC version
>> 4.80 or later, since iATU register area is separated from core register
>> area, this area is necessary to get from DT independently.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>>   drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
>> index a8dda39..493f105 100644
>> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
>> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
>> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
>>   	if (IS_ERR(priv->pci.dbi_base))
>>   		return PTR_ERR(priv->pci.dbi_base);
>>   
>> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
>> +	if (res) {
>> +		priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
> 
> This isn't config space, so this function shouldn't be used.
> 
> Use devm_platform_ioremap_resource_byname().

Indeed. I'll replace with it.

>> +		if (IS_ERR(priv->pci.atu_base))
>> +			priv->pci.atu_base = NULL;
>> +	}
>> +
>>   	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
>>   	priv->base = devm_ioremap_resource(dev, res);
> 
> Feel free to convert this one too.

This should be replaced as well.

Thank you,
  
---
Best Regards
Kunihiko Hayashi

^ permalink raw reply

* [V7 PATCH] dt-bindings: Added device tree binding for max98390
From: Steve Lee @ 2020-06-02  8:43 UTC (permalink / raw)
  To: lgirdwood, broonie, robh+dt, alsa-devel, devicetree, linux-kernel
  Cc: ryan.lee.maxim, ryans.lee, steves.lee.maxim, Steve Lee

Add DT binding of max98390 amplifier driver.

Signed-off-by: Steve Lee <steves.lee@maximintegrated.com>
---

Changed since V6:
	* Re-confirm yaml dt binding check
	* Add minimum and maximum value for each temperature_calib and r0_calib
	* Add maxim prefix for naming.
Changed since V5:
	* Change txt to yaml and fix up the examples.
Changed since V4:
	* No changes.
Changed since V3:
	* No changes.
Changed since V2:
	* No changes.
Changed since V1:
	* Modified sample text in example

 .../bindings/sound/maxim,max98390.yaml        | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/maxim,max98390.yaml

diff --git a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml
new file mode 100644
index 000000000000..e5ac35280da3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/maxim,max98390.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Integrated MAX98390 Speaker Amplifier with Integrated Dynamic Speaker Management
+
+maintainers:
+  - Steve Lee <steves.lee@maximintegrated.com>
+
+properties:
+  compatible:
+      const: maxim,max98390
+
+  reg:
+    maxItems: 1
+    description: I2C address of the device.
+
+  maxim,temperature_calib:
+    allOf:
+      - $ref: /schemas/types.yaml#/definitions/uint32
+    description: The calculated temperature data was measured while doing the calibration.
+    minimum: 0
+    maximum: 65535
+
+  maxim,r0_calib:
+    allOf:
+      - $ref: /schemas/types.yaml#/definitions/uint32
+    description: This is r0 calibration data which was measured in factory mode.
+    minimum: 1
+    maximum: 8388607
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+      max98390: amplifier@38 {
+        compatible = "maxim,max98390";
+        reg = <0x38>;
+        maxim,temperature_calib = <1024>;
+        maxim,r0_calib = <100232>;
+      };
+    };
-- 
2.17.1


^ permalink raw reply related

* Re: [PATCH 10/14] dt-bindings: clock: sparx5: Add Sparx5 SoC DPLL clock
From: Lars Povlsen @ 2020-06-02  8:39 UTC (permalink / raw)
  To: Rob Herring
  Cc: Lars Povlsen, SoC Team, Arnd Bergmann, Stephen Boyd,
	Linus Walleij, Steen Hegelund, Microchip Linux Driver Support,
	Olof Johansson, Michael Turquette, devicetree, linux-clk,
	linux-gpio, linux-arm-kernel, linux-kernel, Alexandre Belloni
In-Reply-To: <20200528021826.GA3221035@bogus>


Rob Herring writes:

> On Wed, May 13, 2020 at 02:55:28PM +0200, Lars Povlsen wrote:
>> This add the DT bindings documentation for the Sparx5 SoC DPLL clock
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>>  .../bindings/clock/microchip,sparx5-dpll.yaml | 46 +++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> new file mode 100644
>> index 0000000000000..594007d8fc59a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> @@ -0,0 +1,46 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 DPLL Clock
>> +
>> +maintainers:
>> +  - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |
>> +  The Sparx5 DPLL clock controller generates and supplies clock to
>> +  various peripherals within the SoC.
>> +
>> +  This binding uses common clock bindings
>> +  [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +
>> +properties:
>> +  compatible:
>> +    const: microchip,sparx5-dpll
>> +
>> +  reg:
>> +    items:
>> +      - description: dpll registers
>
> For a single entry, just:
>
> maxItems: 1

Ok.

>
>> +
>> +  '#clock-cells':
>> +    const: 1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - '#clock-cells'
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  # Clock provider for eMMC:
>> +  - |
>> +    clks: clks@61110000c {
>
> clock-controller@1110000c {
>

Got that.

>> +         compatible = "microchip,sparx5-dpll";
>> +         #clock-cells = <1>;
>> +         reg = <0x1110000c 0x24>;
>
> Looks like this is a sub-block in some other h/w block. What's the
> parent device? That should be described and this should be part of it
> either as a single node or a child node. Without a complete view of what
> this block has I can't provide any guidance.

No, as Alex noted to a similar comment in the temp. sensor driver, the
chip is using packed register spaces predominantly. So don't put too
much into the register offsets.

---Lars

>
> Rob

--
Lars Povlsen,
Microchip

^ permalink raw reply

* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-06-02  8:21 UTC (permalink / raw)
  To: Lars Povlsen
  Cc: Serge Semin, Mark Brown, SoC Team, devicetree, linux-kernel,
	linux-spi, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <87img9q3sb.fsf@soft-dev15.microsemi.net>

On Tue, Jun 02, 2020 at 10:18:28AM +0200, Lars Povlsen wrote:
> 
> Serge Semin writes:
> 
> > Hello Lars,
> >
> > On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> >> This is an add-on series to the main SoC Sparx5 series
> >> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
> >>
> >> The series add support for Sparx5 on top of the existing
> >> ocelot/jaguar2 spi driver.
> >>
> >> It spins off the existing support for the MSCC platforms into a
> >> separate driver, as adding new platforms from the MSCC/Microchip
> >> product lines will further complicate (clutter) the original driver.
> >>
> >> New YAML dt-bindings are provided for the resulting driver.
> >>
> >> It is expected that the DT patches are to be taken directly by the arm-soc
> >> maintainers.
> >
> > Regarding our cooperation. It can be implemented as follows. Since your patchset
> > is less cumbersome than mine and is more ready to be integrated into the generic DW
> > APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> > to be further merged into the kernel version of the driver. After that I'll have
> > my code altered so it could be applied on top of your patches. When everything
> > is done we'll have a more comprehensive DW APB SSI driver with poll-based
> > PIO operations support, new features like rx-delay, etc.
> >
> 
> Hi Serge!
> 
> I think I would be able to work on the SPI patches this week. Should I
> base it on the current spi-next or 5.7? Then address the comments and
> send out a new revision?
> 
> Thanks for reaching out.

Sorry for a delay. I had to finish urgent tasks first. I'll give my review comments
shortly today.

-Sergey

> 
> ---Lars
> 
> > Thank you one more time for the series you've shared with us. Let's see what can
> > be done to improve it...
> >
> > -Sergey
> >
> >>
> >> Lars Povlsen (10):
> >>   spi: dw: Add support for polled operation via no IRQ specified in DT
> >>   spi: dw: Add support for RX sample delay register
> >>   spi: dw: Add support for client driver memory operations
> >>   dt-bindings: spi: Add bindings for spi-dw-mchp
> >>   spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> >>   dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> >>   spi: spi-dw-mchp: Add Sparx5 support
> >>   arm64: dts: sparx5: Add SPI controller
> >>   arm64: dts: sparx5: Add spi-nor support
> >>   arm64: dts: sparx5: Add spi-nand devices
> >>
> >>  .../bindings/spi/mscc,ocelot-spi.yaml         |  89 ++++
> >>  .../bindings/spi/snps,dw-apb-ssi.txt          |   7 +-
> >>  MAINTAINERS                                   |   2 +
> >>  arch/arm64/boot/dts/microchip/sparx5.dtsi     |  37 ++
> >>  .../boot/dts/microchip/sparx5_pcb125.dts      |  16 +
> >>  .../boot/dts/microchip/sparx5_pcb134.dts      |  22 +
> >>  .../dts/microchip/sparx5_pcb134_board.dtsi    |   9 +
> >>  .../boot/dts/microchip/sparx5_pcb135.dts      |  23 +
> >>  .../dts/microchip/sparx5_pcb135_board.dtsi    |   9 +
> >>  arch/mips/configs/generic/board-ocelot.config |   2 +-
> >>  drivers/spi/Kconfig                           |   7 +
> >>  drivers/spi/Makefile                          |   1 +
> >>  drivers/spi/spi-dw-mchp.c                     | 399 ++++++++++++++++++
> >>  drivers/spi/spi-dw-mmio.c                     |  93 ----
> >>  drivers/spi/spi-dw.c                          |  31 +-
> >>  drivers/spi/spi-dw.h                          |   4 +
> >>  16 files changed, 644 insertions(+), 107 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> >>  create mode 100644 drivers/spi/spi-dw-mchp.c
> >>
> >> --
> >> 2.26.2
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> --
> Lars Povlsen,
> Microchip

^ permalink raw reply

* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Lars Povlsen @ 2020-06-02  8:18 UTC (permalink / raw)
  To: Serge Semin
  Cc: Lars Povlsen, Serge Semin, Mark Brown, SoC Team, devicetree,
	linux-kernel, linux-spi, Microchip Linux Driver Support,
	linux-arm-kernel
In-Reply-To: <20200529162130.hsjcde27xhohl6jl@mobilestation>


Serge Semin writes:

> Hello Lars,
>
> On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
>> This is an add-on series to the main SoC Sparx5 series
>> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
>>
>> The series add support for Sparx5 on top of the existing
>> ocelot/jaguar2 spi driver.
>>
>> It spins off the existing support for the MSCC platforms into a
>> separate driver, as adding new platforms from the MSCC/Microchip
>> product lines will further complicate (clutter) the original driver.
>>
>> New YAML dt-bindings are provided for the resulting driver.
>>
>> It is expected that the DT patches are to be taken directly by the arm-soc
>> maintainers.
>
> Regarding our cooperation. It can be implemented as follows. Since your patchset
> is less cumbersome than mine and is more ready to be integrated into the generic DW
> APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> to be further merged into the kernel version of the driver. After that I'll have
> my code altered so it could be applied on top of your patches. When everything
> is done we'll have a more comprehensive DW APB SSI driver with poll-based
> PIO operations support, new features like rx-delay, etc.
>

Hi Serge!

I think I would be able to work on the SPI patches this week. Should I
base it on the current spi-next or 5.7? Then address the comments and
send out a new revision?

Thanks for reaching out.

---Lars

> Thank you one more time for the series you've shared with us. Let's see what can
> be done to improve it...
>
> -Sergey
>
>>
>> Lars Povlsen (10):
>>   spi: dw: Add support for polled operation via no IRQ specified in DT
>>   spi: dw: Add support for RX sample delay register
>>   spi: dw: Add support for client driver memory operations
>>   dt-bindings: spi: Add bindings for spi-dw-mchp
>>   spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
>>   dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
>>   spi: spi-dw-mchp: Add Sparx5 support
>>   arm64: dts: sparx5: Add SPI controller
>>   arm64: dts: sparx5: Add spi-nor support
>>   arm64: dts: sparx5: Add spi-nand devices
>>
>>  .../bindings/spi/mscc,ocelot-spi.yaml         |  89 ++++
>>  .../bindings/spi/snps,dw-apb-ssi.txt          |   7 +-
>>  MAINTAINERS                                   |   2 +
>>  arch/arm64/boot/dts/microchip/sparx5.dtsi     |  37 ++
>>  .../boot/dts/microchip/sparx5_pcb125.dts      |  16 +
>>  .../boot/dts/microchip/sparx5_pcb134.dts      |  22 +
>>  .../dts/microchip/sparx5_pcb134_board.dtsi    |   9 +
>>  .../boot/dts/microchip/sparx5_pcb135.dts      |  23 +
>>  .../dts/microchip/sparx5_pcb135_board.dtsi    |   9 +
>>  arch/mips/configs/generic/board-ocelot.config |   2 +-
>>  drivers/spi/Kconfig                           |   7 +
>>  drivers/spi/Makefile                          |   1 +
>>  drivers/spi/spi-dw-mchp.c                     | 399 ++++++++++++++++++
>>  drivers/spi/spi-dw-mmio.c                     |  93 ----
>>  drivers/spi/spi-dw.c                          |  31 +-
>>  drivers/spi/spi-dw.h                          |   4 +
>>  16 files changed, 644 insertions(+), 107 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
>>  create mode 100644 drivers/spi/spi-dw-mchp.c
>>
>> --
>> 2.26.2
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
Lars Povlsen,
Microchip

^ permalink raw reply

* [PATCH v6 2/2] hwrng: add sec-rng driver
From: Neal Liu @ 2020-06-02  8:14 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
	Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
  Cc: Neal Liu, linux-crypto, devicetree, linux-arm-kernel,
	linux-mediatek, lkml, wsd_upstream, Crystal Guo
In-Reply-To: <1591085678-22764-1-git-send-email-neal.liu@mediatek.com>

For security awareness SoCs on ARMv8 with TrustZone enabled,
peripherals like entropy sources is not accessible from normal world
(linux) and rather accessible from secure world (HYP/ATF/TEE) only.
This driver aims to provide a generic interface to Arm Trusted
Firmware or Hypervisor rng service.

Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
 drivers/char/hw_random/Kconfig   |   13 ++++
 drivers/char/hw_random/Makefile  |    1 +
 drivers/char/hw_random/sec-rng.c |  155 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 169 insertions(+)
 create mode 100644 drivers/char/hw_random/sec-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 9bc46da..cb9c8a9 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -474,6 +474,19 @@ config HW_RANDOM_KEYSTONE
 	help
 	  This option enables Keystone's hardware random generator.
 
+config HW_RANDOM_SECURE
+	tristate "Arm Security Random Number Generator support"
+	depends on HAVE_ARM_SMCCC || COMPILE_TEST
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the Arm Security
+	  Random Number Generator.
+
+	  To compile this driver as a module, choose M here. the
+	  module will be called sec-rng.
+
+	  If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index a7801b4..04533d1 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -41,3 +41,4 @@ obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
 obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
 obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
 obj-$(CONFIG_HW_RANDOM_NPCM) += npcm-rng.o
+obj-$(CONFIG_HW_RANDOM_SECURE) += sec-rng.o
diff --git a/drivers/char/hw_random/sec-rng.c b/drivers/char/hw_random/sec-rng.c
new file mode 100644
index 0000000..c6d3872
--- /dev/null
+++ b/drivers/char/hw_random/sec-rng.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/hw_random.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define SMC_RET_NUM	4
+#define SEC_RND_SIZE	(sizeof(u32) * SMC_RET_NUM)
+
+#define HWRNG_SMC_FAST_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_SIP, (func_num))
+
+#define to_sec_rng(p)	container_of(p, struct sec_rng_priv, rng)
+
+typedef void (sec_rng_fn)(unsigned long, unsigned long, unsigned long,
+			  unsigned long, unsigned long, unsigned long,
+			  unsigned long, unsigned long,
+			  struct arm_smccc_res *);
+
+struct sec_rng_priv {
+	u16 func_num;
+	sec_rng_fn *rng_fn;
+	struct hwrng rng;
+};
+
+/* Simple wrapper functions to be able to use a function pointer */
+static void sec_rng_smc(unsigned long a0, unsigned long a1,
+			unsigned long a2, unsigned long a3,
+			unsigned long a4, unsigned long a5,
+			unsigned long a6, unsigned long a7,
+			struct arm_smccc_res *res)
+{
+	arm_smccc_smc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+}
+
+static void sec_rng_hvc(unsigned long a0, unsigned long a1,
+			unsigned long a2, unsigned long a3,
+			unsigned long a4, unsigned long a5,
+			unsigned long a6, unsigned long a7,
+			struct arm_smccc_res *res)
+{
+	arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+}
+
+static bool __sec_get_rnd(struct sec_rng_priv *priv, uint32_t *val)
+{
+	struct arm_smccc_res res;
+
+	priv->rng_fn(HWRNG_SMC_FAST_CALL_VAL(priv->func_num),
+			0, 0, 0, 0, 0, 0, 0, &res);
+
+	if (!res.a0 && !res.a1 && !res.a2 && !res.a3)
+		return false;
+
+	val[0] = res.a0;
+	val[1] = res.a1;
+	val[2] = res.a2;
+	val[3] = res.a3;
+
+	return true;
+}
+
+static int sec_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	struct sec_rng_priv *priv = to_sec_rng(rng);
+	u32 val[4] = {0};
+	int retval = 0;
+	int i;
+
+	while (max >= SEC_RND_SIZE) {
+		if (!__sec_get_rnd(priv, val))
+			return retval;
+
+		for (i = 0; i < SMC_RET_NUM; i++) {
+			*(u32 *)buf = val[i];
+			buf += sizeof(u32);
+		}
+
+		retval += SEC_RND_SIZE;
+		max -= SEC_RND_SIZE;
+	}
+
+	return retval;
+}
+
+static int sec_rng_probe(struct platform_device *pdev)
+{
+	struct sec_rng_priv *priv;
+	const char *method;
+	int ret;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	if (of_property_read_string(pdev->dev.of_node, "method", &method))
+		return -ENXIO;
+
+	if (!strncmp("smc", method, strlen("smc")))
+		priv->rng_fn = sec_rng_smc;
+	else if (!strncmp("hvc", method, strlen("hvc")))
+		priv->rng_fn = sec_rng_hvc;
+
+	if (IS_ERR(priv->rng_fn)) {
+		dev_err(&pdev->dev, "method %s is not supported\n", method);
+		return -EINVAL;
+	}
+
+	if (of_property_read_u16(pdev->dev.of_node, "method-fid",
+				 &priv->func_num))
+		return -ENXIO;
+
+	if (of_property_read_u16(pdev->dev.of_node, "quality",
+				 &priv->rng.quality))
+		return -ENXIO;
+
+	priv->rng.name = pdev->name;
+	priv->rng.read = sec_rng_read;
+	priv->rng.priv = (unsigned long)&pdev->dev;
+
+	ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to register rng device: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static const struct of_device_id sec_rng_match[] = {
+	{ .compatible = "arm,sec-rng", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sec_rng_match);
+
+static struct platform_driver sec_rng_driver = {
+	.probe = sec_rng_probe,
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.owner = THIS_MODULE,
+		.of_match_table = sec_rng_match,
+	},
+};
+
+module_platform_driver(sec_rng_driver);
+
+MODULE_DESCRIPTION("Security Random Number Generator Driver");
+MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v6 1/2] dt-bindings: rng: add bindings for sec-rng
From: Neal Liu @ 2020-06-02  8:14 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
	Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
  Cc: Neal Liu, linux-crypto, devicetree, linux-arm-kernel,
	linux-mediatek, lkml, wsd_upstream, Crystal Guo
In-Reply-To: <1591085678-22764-1-git-send-email-neal.liu@mediatek.com>

Add bindings for ARM TrustZone based Security Random
Number Generator.

Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
 Documentation/devicetree/bindings/rng/sec-rng.yaml |   53 ++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/sec-rng.yaml

diff --git a/Documentation/devicetree/bindings/rng/sec-rng.yaml b/Documentation/devicetree/bindings/rng/sec-rng.yaml
new file mode 100644
index 0000000..7f4ae50
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/sec-rng.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rng/sec-rng.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Security Random Number Generator
+
+description: |
+  sec-rng is a security random number generator which provides a generic
+  interface to get hardware rnd from Secure state. The Secure state can be
+  Arm Trusted Firmware(ATF), Trusted Execution Environment(TEE), or even
+  EL2 hypervisor.
+
+maintainer:
+  - Neal Liu <neal.liu@mediatek.com>
+
+properties:
+  compatible:
+    enum:
+      - arm,sec-rng
+
+  method:
+    description: The method of calling to Secure state
+    enum:
+      - smc
+      - hvc
+
+  method-fid:
+    description: The function number within the SMC and HVC function identifier
+    maxItems: 1
+
+  quality:
+    description: Estimation of true entropy in RNG's bitstream per 1024 bits
+    maxItems: 1
+
+required:
+  - compatible
+  - methods
+  - method-fid
+  - quality
+
+additionalProperties: false
+
+examples:
+  - |
+    hwrng: hwrng {
+            compatible = "arm,sec-rng";
+            method = "smc";
+            method-fid = /bits/ 16 <0x26a>;
+            quality = /bits/ 16 <900>;
+    };
-- 
1.7.9.5

^ permalink raw reply related

* Security Random Number Generator support
From: Neal Liu @ 2020-06-02  8:14 UTC (permalink / raw)
  To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
	Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
  Cc: Neal Liu, linux-crypto, devicetree, linux-arm-kernel,
	linux-mediatek, lkml, wsd_upstream, Crystal Guo

These patch series introduce a security random number generator
which provides a generic interface to get hardware rnd from Secure
state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
Execution Environment(TEE), or even EL2 hypervisor.

Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
For security awareness SoCs on ARMv8 with TrustZone enabled,
peripherals like entropy sources is not accessible from normal world
(linux) and rather accessible from secure world (HYP/ATF/TEE) only.
This driver aims to provide a generic interface to Arm Trusted
Firmware or Hypervisor rng service.


changes since v1:
- rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can reuse
  this driver.
  - refine coding style and unnecessary check.

  changes since v2:
  - remove unused comments.
  - remove redundant variable.

  changes since v3:
  - add dt-bindings for MediaTek rng with TrustZone enabled.
  - revise HWRNG SMC call fid.

  changes since v4:
  - move bindings to the arm/firmware directory.
  - revise driver init flow to check more property.

  changes since v5:
  - refactor to more generic security rng driver which
    is not platform specific.

*** BLURB HERE ***

Neal Liu (2):
  dt-bindings: rng: add bindings for sec-rng
  hwrng: add sec-rng driver

 .../devicetree/bindings/rng/sec-rng.yaml      |  53 ++++++
 drivers/char/hw_random/Kconfig                |  13 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/sec-rng.c              | 155 ++++++++++++++++++
 4 files changed, 222 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/sec-rng.yaml
 create mode 100644 drivers/char/hw_random/sec-rng.c

-- 
2.18.0

^ permalink raw reply

* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: Tomi Valkeinen @ 2020-06-02  8:13 UTC (permalink / raw)
  To: santosh.shilimkar, Jyri Sarha, dri-devel, ssantosh,
	linux-arm-kernel, devicetree
  Cc: mark.rutland, praneeth, robh+dt, peter.ujfalusi, tomi.valkeinen,
	laurent.pinchart
In-Reply-To: <6749076a-cbc1-d8e2-bc35-2e2a9ad80a6d@oracle.com>

Hi Santosh,

On 14/02/2020 19:40, santosh.shilimkar@oracle.com wrote:
> On 2/14/20 1:22 AM, Jyri Sarha wrote:
>> Resend because the earlier recipient list was wrong.
>>
>> Now that drm/tidss is queued for mainline, lets add display support for
>> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
>> should not harm to have the dts changes in place before that.
>>
>> Jyri Sarha (2):
>>    ARM: dts: keystone-k2g: Add DSS node
>>    ARM: dts: keystone-k2g-evm: add HDMI video support
>>
>>   arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
>>   arch/arm/boot/dts/keystone-k2g.dtsi    |  22 ++++++
>>   2 files changed, 123 insertions(+)
>>
> Ok. Will add this to the next queue.

What happened with this one? It used to be in linux-next, but now I don't see it anymore.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox