* [PATCH 5/9] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-05-24 5:58 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Document devicetree bindings for ROHM BD71837 PMIC clock output.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
.../bindings/clock/rohm,bd71837-clock.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
new file mode 100644
index 000000000000..9759fd145781
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
@@ -0,0 +1,37 @@
+ROHM BD71837 Power Management Integrated Circuit clock bindings
+
+BD71837 clock node should be sub node of the BD71837 MFD node.
+See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+
+Required properties:
+- compatible : Should be "rohm,bd71837-clk"
+- clock-frequency : Should be 32768
+- #clock-cells : Should be 0
+
+Optional properties:
+- clock-output-names : Should contain name for output clock.
+ Name "bd71837-32k-out" is used if this is not given.
+
+
+Example:
+
+pmic: bd71837@4b {
+ compatible = "rohm,bd71837";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 GPIO_ACTIVE_LOW>;
+ interrupt-names = "irq";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+
+ /* Clock node */
+ clk: bd71837-32k-out {
+ compatible = "rohm,bd71837-clk";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "bd71837-32k-out";
+ };
+};
--
2.14.3
^ permalink raw reply related
* [PATCH 4/9] regulator: bd71837: Devicetree bindings for BD71837 regulators
From: Matti Vaittinen @ 2018-05-24 5:57 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Document devicetree bindings for ROHM BD71837 PMIC regulators.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
.../bindings/regulator/rohm,bd71837-regulator.txt | 124 +++++++++++++++++++++
1 file changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
new file mode 100644
index 000000000000..a43230143b66
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
@@ -0,0 +1,124 @@
+ROHM BD71837 Power Management Integrated Circuit (PMIC) regulator bindings
+
+BD71837MWV is a programmable Power Management
+IC (PMIC) for powering single-core, dual-core, and
+quad-core SoC’s such as NXP-i.MX 8M. It is optimized
+for low BOM cost and compact solution footprint. It
+integrates 8 Buck regulators and 7 LDO’s to provide all
+the power rails required by the SoC and the commonly
+used peripherals.
+
+Required properties:
+ - compatible: should be "rohm,bd71837-pmic".
+ - regulator-name: should be "buck1", ..., "buck8" and "ldo1", ..., "ldo7"
+
+List of regulators provided by this controller. BD71837 regulators node
+should be sub node of the BD71837 MFD node. See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+Regulator nodes should be named to BUCK_<number> and LDO_<number>. The
+definition for each of these nodes is defined using the standard
+binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, BUCK7, BUCK8
+LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+regulators {
+ compatible = "rohm,bd71837-pmic";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ buck1: BUCK1 {
+ pmic-supply = <&vmmcsd_fixed>;
+ regulator-name = "buck1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-ramp-delay = <1250>;
+ };
+ buck2: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ };
+ buck3: BUCK3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ };
+ buck4: BUCK4 {
+ regulator-name = "buck4";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ };
+ buck5: BUCK5 {
+ regulator-name = "buck5";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ };
+ buck6: BUCK6 {
+ regulator-name = "buck6";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ buck7: BUCK7 {
+ regulator-name = "buck7";
+ regulator-min-microvolt = <1605000>;
+ regulator-max-microvolt = <1995000>;
+ };
+ buck8: BUCK8 {
+ regulator-name = "buck8";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+ ldo2: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-boot-on;
+ };
+ ldo3: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo4: LDO4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ ldo5: LDO5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ ldo6: LDO6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ ldo7_reg: LDO7 {
+ regulator-name = "ldo7";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+
--
2.14.3
^ permalink raw reply related
* [PATCH 3/9] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-05-24 5:57 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Document devicetree bindings for ROHM BD71837 PMIC MFD.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
.../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
new file mode 100644
index 000000000000..b00c3753b454
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
@@ -0,0 +1,55 @@
+* ROHM BD71837 Power Management Integrated Circuit bindings
+
+BD71837MWV is a programmable Power Management IC for powering single-core,
+dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
+low BOM cost and compact solution footprint. It integrates 8 Buck
+egulators and 7 LDO’s to provide all the power rails required by the SoC and
+the commonly used peripherals.
+
+Required properties:
+ - compatible : Should be "rohm,bd71837".
+ - reg : I2C slave address.
+ - interrupt-parent : Phandle to the parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller : Marks the device node as an interrupt controller.
+ - #interrupt-cells : The number of cells to describe an IRQ, should be 1 or 2.
+ The first cell is the IRQ number.
+ The second cell if present is the flags, encoded as trigger
+ masks from ../interrupt-controller/interrupts.txt.
+ - regulators: : List of child nodes that specify the regulators
+ Please see ../regulator/rohm,bd71837-regulator.txt
+ - clock: : Please see ../clock/rohm,bd71837-clock.txt
+
+Example:
+
+ pmic: bd71837@4b {
+ compatible = "rohm,bd71837";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 GPIO_ACTIVE_LOW>;
+ interrupt-names = "irq";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+
+ regulators {
+ compatible = "rohm,bd71837-pmic";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ buck1: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-ramp-delay = <1250>;
+ };
+ ...
+ };
+ clk: bd71837-32k-out {
+ compatible = "rohm,bd71837-clk";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "bd71837-32k-out";
+ };
+ };
--
2.14.3
^ permalink raw reply related
* [PATCH 2/9] mfd: bd71837: build BD71837 PMIC MFD driver
From: Matti Vaittinen @ 2018-05-24 5:56 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Configuration options and Makefile for BD71837 PMIC MFD driver
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/mfd/Kconfig | 13 +++++++++++++
drivers/mfd/Makefile | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..7aa05fc9ed8e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1787,6 +1787,19 @@ config MFD_STW481X
in various ST Microelectronics and ST-Ericsson embedded
Nomadik series.
+config MFD_BD71837
+ bool "BD71837 Power Management chip"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select MFD_CORE
+ help
+ Select this option to get support for the ROHM BD71837
+ Power Management chips. BD71837 is designed to power processors like
+ NXP i.MX8. It contains 8 BUCK outputs and 7 LDOs, voltage monitoring
+ and emergency shut down as well as 32,768KHz clock output.
+
config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e9fd20dba18d..09dc9eb3782c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -227,4 +227,5 @@ obj-$(CONFIG_MFD_STM32_TIMERS) += stm32-timers.o
obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_MFD_SC27XX_PMIC) += sprd-sc27xx-spi.o
obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
+obj-$(CONFIG_MFD_BD71837) += bd71837.o
--
2.14.3
^ permalink raw reply related
* [PATCH 1/9] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-05-24 5:55 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
ROHM BD71837 PMIC MFD driver providing interrupts and support
for two subsystems:
- clk
- Regulators
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/mfd/bd71837.c | 238 +++++++++++++++++++++++++++++++++
include/linux/mfd/bd71837.h | 316 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 554 insertions(+)
create mode 100644 drivers/mfd/bd71837.c
create mode 100644 include/linux/mfd/bd71837.h
diff --git a/drivers/mfd/bd71837.c b/drivers/mfd/bd71837.c
new file mode 100644
index 000000000000..231442c823bd
--- /dev/null
+++ b/drivers/mfd/bd71837.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2018 ROHM Semiconductors */
+/*
+ * bd71837.c -- ROHM BD71837MWV mfd driver
+ */
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/gpio.h>
+#include <linux/regmap.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/bd71837.h>
+
+/* bd71837 multi function cells */
+static struct mfd_cell bd71837_mfd_cells[] = {
+ {
+ .name = "bd71837-clk",
+ .of_compatible = "rohm,bd71837-clk",
+ }, {
+ .name = "bd71837-pmic",
+ .of_compatible = "rohm,bd71837-pmic",
+ },
+};
+
+static const struct regmap_irq bd71837_irqs[] = {
+ [BD71837_INT_SWRST] = {
+ .mask = BD71837_INT_SWRST_MASK,
+ },
+ [BD71837_INT_PWRBTN_S] = {
+ .mask = BD71837_INT_PWRBTN_S_MASK,
+ },
+ [BD71837_INT_PWRBTN_L] = {
+ .mask = BD71837_INT_PWRBTN_L_MASK,
+ },
+ [BD71837_INT_PWRBTN] = {
+ .mask = BD71837_INT_PWRBTN_MASK,
+ },
+ [BD71837_INT_WDOG] = {
+ .mask = BD71837_INT_WDOG_MASK,
+ },
+ [BD71837_INT_ON_REQ] = {
+ .mask = BD71837_INT_ON_REQ_MASK,
+ },
+ [BD71837_INT_STBY_REQ] = {
+ .mask = BD71837_INT_STBY_REQ_MASK,
+ },
+};
+
+static struct regmap_irq_chip bd71837_irq_chip = {
+ .name = "bd71837-irq",
+ .irqs = bd71837_irqs,
+ .num_irqs = ARRAY_SIZE(bd71837_irqs),
+ .num_regs = 1,
+ .irq_reg_stride = 1,
+ .status_base = BD71837_REG_IRQ,
+ .mask_base = BD71837_REG_MIRQ,
+ .mask_invert = false,
+};
+
+static int bd71837_irq_exit(struct bd71837 *bd71837)
+{
+ if (bd71837->chip_irq > 0)
+ regmap_del_irq_chip(bd71837->chip_irq, bd71837->irq_data);
+ return 0;
+}
+
+static const struct regmap_range pmic_status_range = {
+ .range_min = BD71837_REG_IRQ,
+ .range_max = BD71837_REG_POW_STATE,
+};
+
+static const struct regmap_access_table volatile_regs = {
+ .yes_ranges = &pmic_status_range,
+ .n_yes_ranges = 1,
+};
+
+static const struct regmap_config bd71837_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .volatile_table = &volatile_regs,
+ .max_register = BD71837_MAX_REGISTER - 1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id bd71837_of_match[] = {
+ { .compatible = "rohm,bd71837", .data = (void *)0},
+ { },
+};
+MODULE_DEVICE_TABLE(of, bd71837_of_match);
+
+static int bd71837_parse_dt(struct i2c_client *client, struct bd71837_board **b)
+{
+ struct device_node *np = client->dev.of_node;
+ struct bd71837_board *board_info;
+ unsigned int prop;
+ int r;
+ int rv = -ENOMEM;
+
+ board_info = devm_kzalloc(&client->dev, sizeof(*board_info),
+ GFP_KERNEL);
+ if (!board_info)
+ goto err_out;
+
+ if (client->irq) {
+ dev_dbg(&client->dev, "Got irq %d\n", client->irq);
+ board_info->gpio_intr = client->irq;
+ } else {
+ dev_err(&client->dev, "no pmic intr pin available\n");
+ rv = -ENOENT;
+ goto err_intr;
+ }
+ r = of_property_read_u32(np, "irq_base", &prop);
+ if (!r)
+ board_info->irq_base = prop;
+ else
+ board_info->irq_base = 0;
+
+ rv = 0;
+ *b = board_info;
+ if (0) {
+err_intr:
+ devm_kfree(&client->dev, board_info);
+err_out:
+ dev_err(&client->dev, "failed to parse device-tree (%d)\n", rv);
+ }
+ return rv;
+}
+#endif //CONFIG_OF
+
+static int bd71837_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct bd71837 *bd71837;
+ struct bd71837_board *pmic_plat_data;
+ int ret = -EINVAL;
+
+ pmic_plat_data = dev_get_platdata(&i2c->dev);
+
+ if (!pmic_plat_data && i2c->dev.of_node)
+ ret = bd71837_parse_dt(i2c, &pmic_plat_data);
+
+ if (!pmic_plat_data)
+ return ret;
+
+ bd71837 = devm_kzalloc(&i2c->dev, sizeof(struct bd71837), GFP_KERNEL);
+ if (bd71837 == NULL)
+ return -ENOMEM;
+
+ bd71837->of_plat_data = pmic_plat_data;
+ i2c_set_clientdata(i2c, bd71837);
+ bd71837->dev = &i2c->dev;
+ bd71837->i2c_client = i2c;
+ bd71837->chip_irq = pmic_plat_data->gpio_intr;
+
+ bd71837->regmap = devm_regmap_init_i2c(i2c, &bd71837_regmap_config);
+ if (IS_ERR(bd71837->regmap)) {
+ ret = PTR_ERR(bd71837->regmap);
+ dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ goto err_out;
+ }
+
+ ret = bd71837_reg_read(bd71837, BD71837_REG_REV);
+ if (ret < 0) {
+ dev_err(bd71837->dev,
+ "%s(): Read BD71837_REG_DEVICE failed!\n", __func__);
+ goto err_out;
+ }
+
+ ret = regmap_add_irq_chip(bd71837->regmap, bd71837->chip_irq,
+ IRQF_ONESHOT, 0,
+ &bd71837_irq_chip, &bd71837->irq_data);
+ if (ret < 0) {
+ dev_err(bd71837->dev, "Failed to add irq_chip %d\n", ret);
+ goto err_out;
+ }
+
+ ret = mfd_add_devices(bd71837->dev, PLATFORM_DEVID_AUTO,
+ bd71837_mfd_cells, ARRAY_SIZE(bd71837_mfd_cells),
+ NULL, 0,
+ regmap_irq_get_domain(bd71837->irq_data));
+ if (ret)
+ regmap_del_irq_chip(bd71837->chip_irq, bd71837->irq_data);
+err_out:
+
+ return ret;
+}
+
+static int bd71837_i2c_remove(struct i2c_client *i2c)
+{
+ struct bd71837 *bd71837 = i2c_get_clientdata(i2c);
+
+ bd71837_irq_exit(bd71837);
+ mfd_remove_devices(bd71837->dev);
+
+ return 0;
+}
+
+static const struct i2c_device_id bd71837_i2c_id[] = {
+ { .name = "bd71837", },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, bd71837_i2c_id);
+
+static struct i2c_driver bd71837_i2c_driver = {
+ .driver = {
+ .name = "bd71837-mfd",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(bd71837_of_match),
+ },
+ .probe = bd71837_i2c_probe,
+ .remove = bd71837_i2c_remove,
+ .id_table = bd71837_i2c_id,
+};
+
+static int __init bd71837_i2c_init(void)
+{
+ return i2c_add_driver(&bd71837_i2c_driver);
+}
+/* init early so consumer devices can complete system boot */
+subsys_initcall(bd71837_i2c_init);
+
+static void __exit bd71837_i2c_exit(void)
+{
+ i2c_del_driver(&bd71837_i2c_driver);
+}
+module_exit(bd71837_i2c_exit);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD71837 chip multi-function driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/bd71837.h b/include/linux/mfd/bd71837.h
new file mode 100644
index 000000000000..ba9be05cc61e
--- /dev/null
+++ b/include/linux/mfd/bd71837.h
@@ -0,0 +1,316 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 ROHM Semiconductors */
+
+/*
+ * ROHM BD71837MWV header file
+ */
+
+#ifndef __LINUX_MFD_BD71837_H__
+#define __LINUX_MFD_BD71837_H__
+
+#include <linux/regmap.h>
+
+enum {
+ BD71837_BUCK1 = 0,
+ BD71837_BUCK2,
+ BD71837_BUCK3,
+ BD71837_BUCK4,
+ BD71837_BUCK5,
+ BD71837_BUCK6,
+ BD71837_BUCK7,
+ BD71837_BUCK8,
+ BD71837_LDO1,
+ BD71837_LDO2,
+ BD71837_LDO3,
+ BD71837_LDO4,
+ BD71837_LDO5,
+ BD71837_LDO6,
+ BD71837_LDO7,
+ BD71837_REGULATOR_CNT,
+};
+
+#define BD71837_SUPPLY_STATE_ENABLED 0x1
+
+#define BD71837_BUCK1_VOLTAGE_NUM 0x40
+#define BD71837_BUCK2_VOLTAGE_NUM 0x40
+#define BD71837_BUCK3_VOLTAGE_NUM 0x40
+#define BD71837_BUCK4_VOLTAGE_NUM 0x40
+
+#define BD71837_BUCK5_VOLTAGE_NUM 0x08
+#define BD71837_BUCK6_VOLTAGE_NUM 0x04
+#define BD71837_BUCK7_VOLTAGE_NUM 0x08
+#define BD71837_BUCK8_VOLTAGE_NUM 0x40
+
+#define BD71837_LDO1_VOLTAGE_NUM 0x04
+#define BD71837_LDO2_VOLTAGE_NUM 0x02
+#define BD71837_LDO3_VOLTAGE_NUM 0x10
+#define BD71837_LDO4_VOLTAGE_NUM 0x10
+#define BD71837_LDO5_VOLTAGE_NUM 0x10
+#define BD71837_LDO6_VOLTAGE_NUM 0x10
+#define BD71837_LDO7_VOLTAGE_NUM 0x10
+
+enum {
+ BD71837_REG_REV = 0x00,
+ BD71837_REG_SWRESET = 0x01,
+ BD71837_REG_I2C_DEV = 0x02,
+ BD71837_REG_PWRCTRL0 = 0x03,
+ BD71837_REG_PWRCTRL1 = 0x04,
+ BD71837_REG_BUCK1_CTRL = 0x05,
+ BD71837_REG_BUCK2_CTRL = 0x06,
+ BD71837_REG_BUCK3_CTRL = 0x07,
+ BD71837_REG_BUCK4_CTRL = 0x08,
+ BD71837_REG_BUCK5_CTRL = 0x09,
+ BD71837_REG_BUCK6_CTRL = 0x0A,
+ BD71837_REG_BUCK7_CTRL = 0x0B,
+ BD71837_REG_BUCK8_CTRL = 0x0C,
+ BD71837_REG_BUCK1_VOLT_RUN = 0x0D,
+ BD71837_REG_BUCK1_VOLT_IDLE = 0x0E,
+ BD71837_REG_BUCK1_VOLT_SUSP = 0x0F,
+ BD71837_REG_BUCK2_VOLT_RUN = 0x10,
+ BD71837_REG_BUCK2_VOLT_IDLE = 0x11,
+ BD71837_REG_BUCK3_VOLT_RUN = 0x12,
+ BD71837_REG_BUCK4_VOLT_RUN = 0x13,
+ BD71837_REG_BUCK5_VOLT = 0x14,
+ BD71837_REG_BUCK6_VOLT = 0x15,
+ BD71837_REG_BUCK7_VOLT = 0x16,
+ BD71837_REG_BUCK8_VOLT = 0x17,
+ BD71837_REG_LDO1_VOLT = 0x18,
+ BD71837_REG_LDO2_VOLT = 0x19,
+ BD71837_REG_LDO3_VOLT = 0x1A,
+ BD71837_REG_LDO4_VOLT = 0x1B,
+ BD71837_REG_LDO5_VOLT = 0x1C,
+ BD71837_REG_LDO6_VOLT = 0x1D,
+ BD71837_REG_LDO7_VOLT = 0x1E,
+ BD71837_REG_TRANS_COND0 = 0x1F,
+ BD71837_REG_TRANS_COND1 = 0x20,
+ BD71837_REG_VRFAULTEN = 0x21,
+ BD71837_REG_MVRFLTMASK0 = 0x22,
+ BD71837_REG_MVRFLTMASK1 = 0x23,
+ BD71837_REG_MVRFLTMASK2 = 0x24,
+ BD71837_REG_RCVCFG = 0x25,
+ BD71837_REG_RCVNUM = 0x26,
+ BD71837_REG_PWRONCONFIG0 = 0x27,
+ BD71837_REG_PWRONCONFIG1 = 0x28,
+ BD71837_REG_RESETSRC = 0x29,
+ BD71837_REG_MIRQ = 0x2A,
+ BD71837_REG_IRQ = 0x2B,
+ BD71837_REG_IN_MON = 0x2C,
+ BD71837_REG_POW_STATE = 0x2D,
+ BD71837_REG_OUT32K = 0x2E,
+ BD71837_REG_REGLOCK = 0x2F,
+ BD71837_REG_OTPVER = 0xFF,
+ BD71837_MAX_REGISTER = 0x100,
+};
+
+#define REGLOCK_PWRSEQ 0x1
+#define REGLOCK_VREG 0x10
+
+/* Generic BUCK control masks */
+#define BD71837_BUCK_SEL 0x02
+#define BD71837_BUCK_EN 0x01
+#define BD71837_BUCK_RUN_ON 0x04
+
+/* Generic LDO masks */
+#define BD71837_LDO_SEL 0x80
+#define BD71837_LDO_EN 0x40
+
+/* BD71837_REG_BUCK1_CTRL bits */
+#define BUCK1_RAMPRATE_MASK 0xC0
+#define BUCK1_RAMPRATE_10P00MV 0x0
+#define BUCK1_RAMPRATE_5P00MV 0x1
+#define BUCK1_RAMPRATE_2P50MV 0x2
+#define BUCK1_RAMPRATE_1P25MV 0x3
+
+/* BD71837_REG_BUCK2_CTRL bits */
+#define BUCK2_RAMPRATE_MASK 0xC0
+#define BUCK2_RAMPRATE_10P00MV 0x0
+#define BUCK2_RAMPRATE_5P00MV 0x1
+#define BUCK2_RAMPRATE_2P50MV 0x2
+#define BUCK2_RAMPRATE_1P25MV 0x3
+
+/* BD71837_REG_BUCK3_CTRL bits */
+#define BUCK3_RAMPRATE_MASK 0xC0
+#define BUCK3_RAMPRATE_10P00MV 0x0
+#define BUCK3_RAMPRATE_5P00MV 0x1
+#define BUCK3_RAMPRATE_2P50MV 0x2
+#define BUCK3_RAMPRATE_1P25MV 0x3
+
+/* BD71837_REG_BUCK4_CTRL bits */
+#define BUCK4_RAMPRATE_MASK 0xC0
+#define BUCK4_RAMPRATE_10P00MV 0x0
+#define BUCK4_RAMPRATE_5P00MV 0x1
+#define BUCK4_RAMPRATE_2P50MV 0x2
+#define BUCK4_RAMPRATE_1P25MV 0x3
+
+/* BD71837_REG_BUCK1_VOLT_RUN bits */
+#define BUCK1_RUN_MASK 0x3F
+#define BUCK1_RUN_DEFAULT 0x14
+
+/* BD71837_REG_BUCK1_VOLT_SUSP bits */
+#define BUCK1_SUSP_MASK 0x3F
+#define BUCK1_SUSP_DEFAULT 0x14
+
+/* BD71837_REG_BUCK1_VOLT_IDLE bits */
+#define BUCK1_IDLE_MASK 0x3F
+#define BUCK1_IDLE_DEFAULT 0x14
+
+/* BD71837_REG_BUCK2_VOLT_RUN bits */
+#define BUCK2_RUN_MASK 0x3F
+#define BUCK2_RUN_DEFAULT 0x1E
+
+/* BD71837_REG_BUCK2_VOLT_IDLE bits */
+#define BUCK2_IDLE_MASK 0x3F
+#define BUCK2_IDLE_DEFAULT 0x14
+
+/* BD71837_REG_BUCK3_VOLT_RUN bits */
+#define BUCK3_RUN_MASK 0x3F
+#define BUCK3_RUN_DEFAULT 0x1E
+
+/* BD71837_REG_BUCK4_VOLT_RUN bits */
+#define BUCK4_RUN_MASK 0x3F
+#define BUCK4_RUN_DEFAULT 0x1E
+
+/* BD71837_REG_BUCK5_VOLT bits */
+#define BUCK5_MASK 0x07
+#define BUCK5_DEFAULT 0x02
+
+/* BD71837_REG_BUCK6_VOLT bits */
+#define BUCK6_MASK 0x03
+#define BUCK6_DEFAULT 0x03
+
+/* BD71837_REG_BUCK7_VOLT bits */
+#define BUCK7_MASK 0x07
+#define BUCK7_DEFAULT 0x03
+
+/* BD71837_REG_BUCK8_VOLT bits */
+#define BUCK8_MASK 0x3F
+#define BUCK8_DEFAULT 0x1E
+
+/* BD71837_REG_IRQ bits */
+#define IRQ_SWRST 0x40
+#define IRQ_PWRON_S 0x20
+#define IRQ_PWRON_L 0x10
+#define IRQ_PWRON 0x08
+#define IRQ_WDOG 0x04
+#define IRQ_ON_REQ 0x02
+#define IRQ_STBY_REQ 0x01
+
+/* BD71837_REG_OUT32K bits */
+#define BD71837_OUT32K_EN 0x01
+
+/* BD71837 gated clock rate */
+#define BD71837_CLK_RATE 32768
+
+/* BD71837 irqs */
+enum {
+ BD71837_INT_STBY_REQ,
+ BD71837_INT_ON_REQ,
+ BD71837_INT_WDOG,
+ BD71837_INT_PWRBTN,
+ BD71837_INT_PWRBTN_L,
+ BD71837_INT_PWRBTN_S,
+ BD71837_INT_SWRST
+};
+
+/* BD71837 interrupt masks */
+#define BD71837_INT_SWRST_MASK 0x40
+#define BD71837_INT_PWRBTN_S_MASK 0x20
+#define BD71837_INT_PWRBTN_L_MASK 0x10
+#define BD71837_INT_PWRBTN_MASK 0x8
+#define BD71837_INT_WDOG_MASK 0x4
+#define BD71837_INT_ON_REQ_MASK 0x2
+#define BD71837_INT_STBY_REQ_MASK 0x1
+
+/* BD71837_REG_LDO1_VOLT bits */
+#define LDO1_MASK 0x03
+
+/* BD71837_REG_LDO1_VOLT bits */
+#define LDO2_MASK 0x20
+
+/* BD71837_REG_LDO3_VOLT bits */
+#define LDO3_MASK 0x0F
+
+/* BD71837_REG_LDO4_VOLT bits */
+#define LDO4_MASK 0x0F
+
+/* BD71837_REG_LDO5_VOLT bits */
+#define LDO5_MASK 0x0F
+
+/* BD71837_REG_LDO6_VOLT bits */
+#define LDO6_MASK 0x0F
+
+/* BD71837_REG_LDO7_VOLT bits */
+#define LDO7_MASK 0x0F
+
+struct bd71837;
+struct bd71837_pmic;
+struct bd71837_clk;
+
+/*
+ * Board platform data may be used to initialize regulators.
+ */
+
+struct bd71837_board {
+ struct regulator_init_data *init_data[BD71837_REGULATOR_CNT];
+ int gpio_intr;
+ int irq_base;
+};
+
+struct bd71837 {
+ struct device *dev;
+ struct i2c_client *i2c_client;
+ struct regmap *regmap;
+ unsigned long int id;
+
+ int chip_irq;
+ struct regmap_irq_chip_data *irq_data;
+
+ struct bd71837_pmic *pmic;
+ struct bd71837_clk *clk;
+
+ struct bd71837_board *of_plat_data;
+};
+
+static inline unsigned long int bd71837_chip_id(struct bd71837 *bd71837)
+{
+ return bd71837->id;
+}
+
+/*
+ * bd71837 sub-driver chip access routines
+ */
+
+static inline int bd71837_reg_read(struct bd71837 *bd71837, u8 reg)
+{
+ int r, val;
+
+ r = regmap_read(bd71837->regmap, reg, &val);
+ if (r < 0)
+ return r;
+ return val;
+}
+
+static inline int bd71837_reg_write(struct bd71837 *bd71837, u8 reg,
+ unsigned int val)
+{
+ return regmap_write(bd71837->regmap, reg, val);
+}
+
+static inline int bd71837_set_bits(struct bd71837 *bd71837, u8 reg, u8 mask)
+{
+ return regmap_update_bits(bd71837->regmap, reg, mask, mask);
+}
+
+static inline int bd71837_clear_bits(struct bd71837 *bd71837, u8 reg,
+ u8 mask)
+{
+ return regmap_update_bits(bd71837->regmap, reg, mask, 0);
+}
+
+static inline int bd71837_update_bits(struct bd71837 *bd71837, u8 reg,
+ u8 mask, u8 val)
+{
+ return regmap_update_bits(bd71837->regmap, reg, mask, val);
+}
+
+#endif /* __LINUX_MFD_BD71837_H__ */
--
2.14.3
^ permalink raw reply related
* [PATCH 0/9] mfd/regulator/clk: bd71837: ROHM BD71837 PMIC driver
From: Matti Vaittinen @ 2018-05-24 5:54 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Patch series adding support for ROHM BD71837 PMIC.
BD71837 is a programmable Power Management IC for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
low BOM cost and compact solution footprint. It integrates 8 buck
regulators and 7 LDO’s to provide all the power rails required by the
SoC and the commonly used peripherals.
The driver aims to not limit the usage of PMIC. Thus the buck and LDO
naming is generic and not tied to any specific purposes. However there
is following limitations which make it mostly suitable for use cases
where the processor where PMIC driver is running is powered by the PMIC:
- The PMIC is not re-initialized if it resets. PMIC may reset as a
result of voltage monitoring (over/under voltage) or due to reset
request. Driver is only initializing PMIC at probe. This is not
problem as long as processor controlling PMIC is powered by PMIC.
- The PMIC internal state machine is ignored by driver. Driver assumes
the PMIC is wired so that it is always in "run" state when controlled
by the driver.
patch 1:
MFD driver and definitions bringing interrupt support and
enabling clk and regulator subsystems.
Patch 2:
Kconfig and Makefiles for MFD.
Patches 3, 4 and 5:
device tree binding documents.
Patch 6:
clock subsystem and support for gated clock.
Patch 7:
Kconfig and Makefiles for clock.
Patch 8:
regulator driver supporting 8 bucks and 7 LDOs.
Patch 9:
Kconfig and Makefiles for regulators
This patch series is based on for-mfd-next
---
Matti Vaittinen (9):
mfd: bd71837: mfd driver for ROHM BD71837 PMIC
mfd: bd71837: build BD71837 PMIC MFD driver
mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
regulator: bd71837: Devicetree bindings for BD71837 regulators
clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
clk: bd71837: Add driver for BD71837 PMIC clock
clk: bd71837: Build ROHM BD71837 PMIC clock driver
regulator: bd71837: BD71837 PMIC regulator driver
regulator: bd71837: Build BD71837 regulator driver
.../bindings/clock/rohm,bd71837-clock.txt | 37 ++
.../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 55 ++
.../bindings/regulator/rohm,bd71837-regulator.txt | 124 ++++
drivers/clk/Kconfig | 9 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-bd71837.c | 155 +++++
drivers/mfd/Kconfig | 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/bd71837.c | 238 +++++++
drivers/regulator/Kconfig | 11 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bd71837-regulator.c | 683 +++++++++++++++++++++
include/linux/mfd/bd71837.h | 316 ++++++++++
13 files changed, 1644 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.txt
create mode 100644 drivers/clk/clk-bd71837.c
create mode 100644 drivers/mfd/bd71837.c
create mode 100644 drivers/regulator/bd71837-regulator.c
create mode 100644 include/linux/mfd/bd71837.h
--
2.14.3
^ permalink raw reply
* Re: [PATCH 2/2] mtd: partitions: use DT info for parsing partitions with specified type
From: Rafał Miłecki @ 2018-05-24 5:50 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, linux-mtd, Jonas Gorski,
Rafał Miłecki, Brian Norris, David Woodhouse
In-Reply-To: <20180523202408.632edefa@bbrezillon>
On 23.05.2018 20:24, Boris Brezillon wrote:
> On Wed, 23 May 2018 19:14:48 +0200
> Rafał Miłecki <zajec5@gmail.com> wrote:
>
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This supports nested partitions in a DT. If selected partition has a
>> "compatible" property specified it will be parsed looking for
>> subpartitions.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> drivers/mtd/mtdpart.c | 33 +++++++++++++--------------------
>> 1 file changed, 13 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
>> index f8d3a015cdad..52e2cb35fc79 100644
>> --- a/drivers/mtd/mtdpart.c
>> +++ b/drivers/mtd/mtdpart.c
>> @@ -322,22 +322,6 @@ static inline void free_partition(struct mtd_part *p)
>> kfree(p);
>> }
>>
>> -/**
>> - * mtd_parse_part - parse MTD partition looking for subpartitions
>> - *
>> - * @slave: part that is supposed to be a container and should be parsed
>> - * @types: NULL-terminated array with names of partition parsers to try
>> - *
>> - * Some partitions are kind of containers with extra subpartitions (volumes).
>> - * There can be various formats of such containers. This function tries to use
>> - * specified parsers to analyze given partition and registers found
>> - * subpartitions on success.
>> - */
>> -static int mtd_parse_part(struct mtd_part *slave, const char *const *types)
>> -{
>> - return parse_mtd_partitions(&slave->mtd, types, NULL);
>> -}
>> -
>> static struct mtd_part *allocate_partition(struct mtd_info *parent,
>> const struct mtd_partition *part, int partno,
>> uint64_t cur_offset)
>> @@ -735,8 +719,8 @@ int add_mtd_partitions(struct mtd_info *master,
>>
>> add_mtd_device(&slave->mtd);
>> mtd_add_partition_attrs(slave);
>> - if (parts[i].types)
>> - mtd_parse_part(slave, parts[i].types);
>> + /* Look for subpartitions */
>> + parse_mtd_partitions(&slave->mtd, parts[i].types, NULL);
>>
>> cur_offset = slave->offset + slave->mtd.size;
>> }
>> @@ -812,6 +796,12 @@ static const char * const default_mtd_part_types[] = {
>> NULL
>> };
>>
>> +/* Check DT only when looking for subpartitions. */
>> +static const char * const default_subpartition_types[] = {
>> + "ofpart",
>> + NULL
>> +};
>> +
>> static int mtd_part_do_parse(struct mtd_part_parser *parser,
>> struct mtd_info *master,
>> struct mtd_partitions *pparts,
>> @@ -882,7 +872,9 @@ static int mtd_part_of_parse(struct mtd_info *master,
>> const char *fixed = "fixed-partitions";
>> int ret, err = 0;
>>
>> - np = of_get_child_by_name(mtd_get_of_node(master), "partitions");
>> + np = mtd_get_of_node(master);
>> + if (!mtd_is_partition(master))
>> + np = of_get_child_by_name(np, "partitions");
>> of_property_for_each_string(np, "compatible", prop, compat) {
>> parser = mtd_part_get_compatible_parser(compat);
>> if (!parser)
>> @@ -945,7 +937,8 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
>> int ret, err = 0;
>>
>> if (!types)
>> - types = default_mtd_part_types;
>> + types = mtd_is_partition(master) ? default_subpartition_types :
>> + default_mtd_part_types;
>
> Hm, that means the subparts inherit the parser types from their parent
> if types != NULL? Is that really what we want? And if that's what we
> want, why don't we do the same for types == NULL?
No, unless I'm missing something. In add_mtd_partitions() there is now
a following call:
parse_mtd_partitions(&slave->mtd, parts[i].types, NULL);
In most cases parts[i].types is NULL, unless you're using some
exceptional driver (like bcm47xxpart) which sets "types".
So for each partition parse_mtd_partitions() will be called with "types"
argument almost always set to NULL (no inheriting). That will result in
picking default_subpartition_types.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Taniya Das @ 2018-05-24 5:46 UTC (permalink / raw)
To: Sudeep Holla, linux-kernel, linux-pm, Stephen Boyd, robh
Cc: Rafael J. Wysocki, Viresh Kumar, Rajendra Nayak, Amit Nischal,
devicetree, skannan, amit.kucheria
In-Reply-To: <34b510f5-fd0b-2e28-45b0-f200f9f8d2c5@arm.com>
On 5/23/2018 8:43 PM, Sudeep Holla wrote:
>
>
> On 19/05/18 18:34, Taniya Das wrote:
>> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
>> SoCs. This is required for managing the cpu frequency transitions which are
>> controlled by firmware.
>>
>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
>> ---
>> .../bindings/cpufreq/cpufreq-qcom-fw.txt | 68 ++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
>> new file mode 100644
>> index 0000000..bc912f4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt
>> @@ -0,0 +1,68 @@
>> +Qualcomm Technologies, Inc. CPUFREQ Bindings
>> +
>> +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
>> +SoCs to manage frequency in hardware. It is capable of controlling frequency
>> +for multiple clusters.
>> +
>> +Properties:
>> +- compatible
>> + Usage: required
>> + Value type: <string>
>> + Definition: must be "qcom,cpufreq-fw".
>> +
>
> If the firmware is referred with some other name, better to use that
> than cpufreq
>> +Note that #address-cells, #size-cells, and ranges shall be present to ensure
>> +the cpufreq can address a freq-domain registers.
>> +
>> +A freq-domain sub-node would be defined for the cpus with the following
>> +properties:
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <string>
>> + Definition: must be "cpufreq".
>> +
>> +- reg
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Addresses and sizes for the memory of the perf_base
>> + , lut_base and en_base.
>
> Can you explicitly define each one of them ? Either here or in reg-names.
>
Sure will define each of them in the next series.
>> +- reg-names
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Address names. Must be "perf_base", "lut_base",
>> + "en_base".
>> + Must be specified in the same order as the
>> + corresponding addresses are specified in the reg
>> + property.
>> +
>> +- qcom,cpulist
>> + Usage: required
>> + Value type: <phandles of CPU>
>> + Definition: List of related cpu handles which are under a cluster.
>> +
>
> As already mentioned by Rob and Viresh, better to align with OPP style
> to avoid phandle list of CPUs.
>
I have put down an example device tree node for Rob & Viresh to review.
> Also I see similar bindings for devfreq, can't they be aligned ?
> E.g. lut_base here while it's ftbl_base in devfreq.
>
It is actually the look up table, thus was the name given as "lut". Will
check with Saravana for devfreq and align accordingly.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Viresh Kumar @ 2018-05-24 5:43 UTC (permalink / raw)
To: Taniya Das
Cc: Rob Herring, Rafael J. Wysocki, linux-kernel@vger.kernel.org,
linux-pm, Stephen Boyd, Rajendra Nayak, Amit Nischal, devicetree,
Saravana Kannan, Amit Kucheria
In-Reply-To: <cba1616d-ad12-599b-4351-3c7240de852a@codeaurora.org>
On 24-05-18, 10:48, Taniya Das wrote:
> Hello Rob, Viresh,
>
> Thank you for the comments. If I understand correctly, the device tree nodes
> should look something like the below.
>
> Though I am not sure if any vendor name could be associated in the cpu
> nodes.
Well Rob said Yes to that I think.
> Please suggest if my understanding is wrong.
>
> cpu@0 {
> qcom,freq-domain = <&freq_domain_table0>;
> …
> };
>
> same follows for cpu 1/2/3
>
> cpu@400 {
> qcom,freq-domain = <&freq_domain_table1>;
> …
> };
> same follows for cpu 5/6/7
>
> freq_domain_table0 : freq_table {
> reg = < >, < >, < > ;
> reg-names = "perf_base", "lut_base", "en_base";
> };
>
> freq_domain_table1 : freq_table {
> reg = < >, < >, < > ;
> reg-names = "perf_base", "lut_base", "en_base";
> };
Mostly yes.
--
viresh
^ permalink raw reply
* Re: [PATCH] arm64: dts: sprd: fix typo in 'remote-endpoint'
From: Baolin Wang @ 2018-05-24 5:27 UTC (permalink / raw)
To: Rob Herring, Arnd Bergmann; +Cc: Chunyan Zhang, DTML, Linux ARM, Orson Zhai
In-Reply-To: <CAL_JsqKrsTpgnLfxhcxeucpoh9NkyGwwZq82QUBgJZrdjGYQzg@mail.gmail.com>
On 24 May 2018 at 04:30, Rob Herring <robh@kernel.org> wrote:
> On Tue, May 8, 2018 at 8:58 PM, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
>> Hi Rob,
>>
>> On 8 May 2018 at 23:09, Rob Herring <robh@kernel.org> wrote:
>>> dtc now warns on incomplete OF graph endpoint connections:
>>>
>>> arch/arm64/boot/dts/sprd/sp9860g-1h10.dtb: Warning (graph_endpoint): /soc/stm@10006000/port/endpoint: graph connection to node '/soc/funnel@10001000/ports/port@2/endpoint' is not bidirectional
>>>
>>> The cause is a typo in 'remote-endpoint'.
>>
>> Thanks for fixing this and,
>>
>> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
>
> Is someone going to apply this? Still seeing warnings in linux-next.
I think Arnd will pick up this patch.
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845
From: Rohit Kumar @ 2018-05-24 5:18 UTC (permalink / raw)
To: Bjorn Andersson
Cc: ohad, robh+dt, mark.rutland, linux-remoteproc, devicetree,
linux-kernel, bgoswami, sbpata, asishb, rkarra,
RajendraBabu Medisetti, Krishnamurthy Renu, asishb, Ramlal Karra,
Rohit Kumar
In-Reply-To: <20180523062645.GY14924@minitux>
Thanks Bjorn for reviewing.
On 5/23/2018 11:56 AM, Bjorn Andersson wrote:
> On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:
>
>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
>> @@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
>> "qcom,msm8974-adsp-pil"
>> "qcom,msm8996-adsp-pil"
>> "qcom,msm8996-slpi-pil"
>> + "qcom,sdm845-apss-adsp-pil"
> Afaict there's nothing in this binding that ties this to the apss, so I
> don't think we should base the compatible on this. The differentiation
> is PAS vs non-PAS; so let's start naming the PAS variants
> "qcom,platform-subsystem-pas" and the non-PAS
> "qcom,platform-subsystem-pil" instead.
>
> I.e. please make this "qcom,sdm845-adsp-pil".
>
> More importantly, any resources such as clocks or reset lines should
> come from DT and as such you need to extend the binding quite a bit -
> which I suggest you do by introducing a new binding document.
Sure. Will create new dt-binding document with clocks and reset driver
info added for sdm845 PIL.
>>
>> - interrupts-extended:
>> Usage: required
>> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
>> index 02627ed..759831b 100644
>> --- a/drivers/remoteproc/Makefile
>> +++ b/drivers/remoteproc/Makefile
>> @@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
>> obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
>> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
>> obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
>> -obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp_pil.o
>> +obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp.o
>> +qcom_adsp-objs += qcom_adsp_pil.o qcom_adsp_pil_sdm845.o
>> obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
>> obj-$(CONFIG_QCOM_Q6V5_PIL) += qcom_q6v5_pil.o
>> obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
>> diff --git a/drivers/remoteproc/qcom_adsp_pil.c b/drivers/remoteproc/qcom_adsp_pil.c
> I get the feeling that the main reason for modifying this file is its
> name, not that it reduces the complexity of the final solution. I
> definitely think it's cleaner to have some structural duplication and
> keep this driver handling the various PAS based remoteprocs.
The main intention was to re-use exisiting APIs in PAS based PIL driver
as the major change was
w.r.t. start and stop of ADSP firmware. Load(), interrupt handling and
few other APIs will be same
as done in exisiting PAS based PIL driver.
> Please see the RFC series I posted reducing the duplication between the
> various "Q6V5 drivers".
I went through the RFC. Our code will fit into the design. However, we
will still have some amount of code
duplication between PAS and Non-PAS ADSP PIL driver. Will this be fine?
Please suggest.
Will wait for your response whether to write complete new driver or
reuse exisitng one.
> [..]
>> diff --git a/drivers/remoteproc/qcom_adsp_pil.h b/drivers/remoteproc/qcom_adsp_pil.h
> [..]
>> +static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32 shift)
>> +{
>> + u32 reg_val = 0;
>> +
>> + reg_val = ((readl(reg)) & ~mask_val) | ((set_val << shift) & mask_val);
>> + writel(reg_val, reg);
>> +}
>> +
>> +static inline unsigned int read_bit(void *reg, u32 mask, int shift)
>> +{
>> + return ((readl(reg) & mask) >> shift);
>> +}
> I don't like these helper functions, their prototype is nonstandard and
> makes it really hard to read all the calling code.
>
> I would prefer if you just inline the operations directly, to make it
> clearer what's going on in each case - if not then at least follow the
> prototype of e.g. regmap_udpate_bits(), which people might be used to.
Sure. Will update these APIs to follow standard format used in regmap
and other drivers.
>> +
>> +#endif
>> diff --git a/drivers/remoteproc/qcom_adsp_pil_sdm845.c b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
>> new file mode 100644
>> index 0000000..7518385
>> --- /dev/null
>> +++ b/drivers/remoteproc/qcom_adsp_pil_sdm845.c
>> @@ -0,0 +1,304 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Qualcomm APSS Based ADSP bootup/shutdown ops for SDM845.
>> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +
>> +#include "qcom_adsp_pil.h"
>> +
>> +/* set values */
>> +#define CLK_ENABLE 0x1
>> +#define CLK_DISABLE 0x0
> Just write 0 and 1 in the code, it saves future readers the trouble of
> having to remember if these are special in any way.
OK.
>> +/* time out value */
>> +#define ACK_TIMEOUT 200000
> This is currently given in the rather awkward unit of 5uS. As it's input
> to what should have been a call to readl_poll_timeout() please express
> it in micro seconds.
sure. will do that in next patch
>> +/* mask values */
>> +#define CLK_MASK GENMASK(4, 0)
>> +#define EVB_MASK GENMASK(27, 4)
>> +#define SPIN_CLKOFF_MASK BIT(31)
>> +#define AUDIO_SYNC_RESET_MASK BIT(2)
>> +#define CLK_ENABLE_MASK BIT(0)
>> +#define HAL_CLK_MASK BIT(1)
>> +/* GCC register offsets */
>> +#define GCC_BASE 0x00147000
> This doesn't belong here, expose the resource from the gcc driver using
> existing frameworks.
Ok. Will use gcc clock driver for this.
>> +#define SWAY_CBCR_OFFSET 0x00000008
>> +/*LPASS register base address and offsets*/
>> +#define LPASS_BASE 0x17000000
> This should be in the lpass clock driver.
Sure. Will use clock driver for these.
>> +/*QDSP6SS register base address and offsets*/
>> +#define QDSP6SS_BASE 0x17300000
> This should come from the reg property in DT.
OK
>> +/*TCSR register base address and offsets*/
>> +#define TCSR_BASE 0x01F62000
> Look at how we deal with TCSR in the MSS driver instead.
OK Sure. Thanks for the reference.
>
>> +
>> +#define RPMH_PDC_SYNC_RESET_ADDR 0x0B2E0100
>> +#define AOSS_CC_LPASS_RESTART_ADDR 0x0C2D0000
> Please expose these from an appropriate driver using appropriate
> frameworks.
Sure. Will use reset driver for this.
>> +
>> +struct sdm845_reg {
>> + void __iomem *gcc_base;
>> + void __iomem *lpass_base;
>> + void __iomem *qdsp6ss_base;
>> + void __iomem *tcsr_base;
>> + void __iomem *pdc_sync;
>> + void __iomem *cc_lpass;
> I expect to see only qdsp6ss_base remain here.
OK
>
>> +static int clk_enable_spin(void *reg, int read_shift, int write_shift)
> This should be in the appropriate clock drivers.
Right. Will cleanup this.
>
>> + /* Enable the QDSP6SS AHBM and AHBS clocks */
>> + ret = clk_enable_spin(reg->lpass_base + AHBS_AON_CBCR_OFFSET,
>> + CLK_MASK, 0x0);
>> + if (ret)
>> + return ret;
>> + ret = clk_enable_spin(reg->lpass_base + AHBM_AON_CBCR_OFFSET,
>> + CLK_MASK, 0x0);
>> + if (ret)
>> + return ret;
> Above should be calls to the clock framework.
OK.
>
>> + /* Wait for core to come out of reset */
>> + while ((!(readl(reg->qdsp6ss_base +
>> + BOOT_STATUS_OFFSET))) && (timeout-- > 0))
>> + udelay(5);
> Use readl_poll_timeout() from linux/iopoll.h
OK
>> +
>> + if (!timeout)
>> + return -ETIMEDOUT;
>> +
>> + return 0;
>> +}
>> +
>> +static int sdm845_bringup(struct qcom_adsp *adsp)
> This is called "start" in other places, please use existing naming
> convention to make your code feel familiar to people reading other
> drivers.
OK Sure. Will rename this in next version.
>
>> +{
>> + u32 ret;
> ret is exclusively used to store data of the type "int".
Yep. Will change it.
>> + }
>> + /* Program boot address */
>> + update_bits(reg->qdsp6ss_base + RST_EVB_OFFSET,
>> + EVB_MASK, (adsp->mem_phys) >> 8, 0x4);
> In the WCSS PIL driver this is:
>
> writel(rproc->bootaddr >> 4, wcss->reg_base + QDSP6SS_RST_EVB);
>
> Which I think is the same as you're doing here, although you're shifting
> 8 bits right and then 4 (base 16) to the left.
Right. Will make it similar.
>
>> +
>> + /* Wait for addresses to be programmed before starting adsp */
> That's not what mb() does, it just ensures that any read and writes
> coming after this point isn't reordered with any operations before it.
>
> And as sdm845_adsp_reset() used writel() there is already a wmb() there,
> so you can drop this one.
Sure
>
>> + mb();
>> + ret = sdm845_adsp_reset(adsp);
>> + if (ret)
>> + dev_err(adsp->dev, "%s: De-assert QDSP6 out of reset failed\n",
>> + __func__);
> This string is unique in the kernel, so you don't need __func__.
OK
>
>> +
>> +static int sdm845_bringdown(struct qcom_adsp *adsp)
>> +{
>> + u32 acktimeout = ACK_TIMEOUT;
>> + u32 temp;
> We know this is a temporary variable, name it "val" as we do in the
> other functions.
Sure.
>> + struct sdm845_reg *reg = adsp->priv_reg;
>> +
>> + /* Reset the retention logic */
>> + update_bits(reg->qdsp6ss_base + RET_CFG_OFFSET,
>> + CLK_ENABLE_MASK, CLK_ENABLE, 0x0);
>> + /* Disable the slave way clock to LPASS */
>> + update_bits(reg->gcc_base + SWAY_CBCR_OFFSET,
>> + CLK_ENABLE_MASK, CLK_DISABLE, 0x0);
>> +
>> + /* QDSP6 master port needs to be explicitly halted */
>> + temp = read_bit(reg->tcsr_base + TCSR_LPASS_PWR_ON_OFFSET,
>> + CLK_ENABLE, 0x0);
>> + temp = temp && !read_bit(reg->tcsr_base + TCSR_LPASS_MASTER_IDLE_OFFSET,
>> + CLK_ENABLE, 0x0);
>> + if (temp) {
>> + writel(CLK_ENABLE, reg->tcsr_base + TCSR_LPASS_HALTREQ_OFFSET);
> CLK_ENABLE happens to have the right value, but the value you write is
> "request halt" not "enable clock".
Right. We will remove CLK_ENABLE/DISABLE macros as suggested by you.
>
>> + /* Wait for halt ACK from QDSP6 */
>> + while ((read_bit(reg->tcsr_base + TCSR_LPASS_HALTACK_OFFSET,
>> + CLK_DISABLE, 0x0) == 0) && (acktimeout-- > 0))
>> + udelay(5);
>> +
>> + if (acktimeout) {
>> + if (read_bit(reg->tcsr_base +
>> + TCSR_LPASS_MASTER_IDLE_OFFSET,
>> + CLK_ENABLE, 0x0) != 1)
>> + dev_warn(adsp->dev,
>> + "%s: failed to receive %s\n",
>> + __func__, "TCSR MASTER ACK");
>> + } else {
>> + dev_err(adsp->dev, "%s: failed to receive halt ack\n",
>> + __func__);
>> + return -ETIMEDOUT;
>> + }
>> + }
> Take a look at q6v5proc_halt_axi_port() in qcom_q6v5_pil.c instead of
> this thing.
OK Sure.
>
>> +
>> + /* Assert the LPASS PDC Reset */
>> + update_bits(reg->pdc_sync, AUDIO_SYNC_RESET_MASK,
>> + CLK_ENABLE, 0x2);
> Use https://patchwork.kernel.org/patch/10415991/
>
> reset_control_assert();
Yes. Will do this change in next patchset.
>
>> + /* Place the LPASS processor into reset */
>> + writel(CLK_ENABLE, reg->cc_lpass);
>> + /* wait after asserting subsystem restart from AOSS */
>> + udelay(200);
>> +
>> + /* Clear the halt request for the AXIM and AHBM for Q6 */
>> + writel(CLK_DISABLE, reg->tcsr_base + TCSR_LPASS_HALTREQ_OFFSET);
> Disable the clock that is the halt request register?
Will remove Macro. Its actually clearing halt request.
>
>> +
>> + /* De-assert the LPASS PDC Reset */
>> + update_bits(reg->pdc_sync, AUDIO_SYNC_RESET_MASK,
>> + CLK_DISABLE, 0x2);
> reset_control_deassert();
OK.
>> + /* Remove the LPASS reset */
>> + writel(CLK_DISABLE, reg->cc_lpass);
>> + /* wait after de-asserting subsystem restart from AOSS */
>> + udelay(200);
>> +
>> + return 0;
>> +}
> Regards,
> Bjorn
Thanks,
Rohit
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings
From: Taniya Das @ 2018-05-24 5:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar
Cc: Rafael J. Wysocki, linux-kernel@vger.kernel.org, linux-pm,
Stephen Boyd, Rajendra Nayak, Amit Nischal, devicetree,
Saravana Kannan, Amit Kucheria
In-Reply-To: <CAL_JsqL7VdSjerOioc5cSOyKAAXJuVnPJqp_WbTtwr11UUxq=A@mail.gmail.com>
Hello Rob, Viresh,
Thank you for the comments. If I understand correctly, the device tree
nodes should look something like the below.
Though I am not sure if any vendor name could be associated in the cpu
nodes.
Please suggest if my understanding is wrong.
cpu@0 {
qcom,freq-domain = <&freq_domain_table0>;
…
};
same follows for cpu 1/2/3
cpu@400 {
qcom,freq-domain = <&freq_domain_table1>;
…
};
same follows for cpu 5/6/7
freq_domain_table0 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};
freq_domain_table1 : freq_table {
reg = < >, < >, < > ;
reg-names = "perf_base", "lut_base", "en_base";
};
On 5/23/2018 7:48 PM, Rob Herring wrote:
> On Wed, May 23, 2018 at 12:48 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 22-05-18, 14:31, Rob Herring wrote:
>>> On Sat, May 19, 2018 at 11:04:50PM +0530, Taniya Das wrote:
>>>> + freq-domain-0 {
>>>> + compatible = "cpufreq";
>>>> + reg = <0x17d43920 0x4>,
>>>> + <0x17d43110 0x500>,
>>>> + <0x17d41000 0x4>;
>>>> + reg-names = "perf_base", "lut_base", "en_base";
>>>> + qcom,cpulist = <&CPU0 &CPU1 &CPU2 &CPU3>;
>>
>> I was thinking, can't we add platform specific properties in the CPU
>> nodes ? If yes, then we can point the phandle of fw node from the CPUs
>> and this awkward list can go away.
>
> Yes, that's fine. That would be more like OPP binding in that the CPU
> points to the OPP table rather than the OPP pointing to the CPUs.
>
> With that, you can get rid of the child nodes completely. Just make
> the parent reg property N sets of 3 addresses for N domains.
>
> Rob
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
^ permalink raw reply
* Re: [PATCH] arm64: dts: msm8916: fix Coresight ETF graph connections
From: Ivan T. Ivanov @ 2018-05-24 4:48 UTC (permalink / raw)
To: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Andy Gross, Rob Herring, devicetree
Cc: David Brown, Mathieu Poirier, Ivan T . Ivanov, linux-arm-msm
In-Reply-To: <CAL_JsqL8qBiJUMyUEcih07UoFSAghn6Amfo8OfY-pKU-QX2_mw@mail.gmail.com>
Quoting Rob Herring (2018-05-23 23:29:29)
> On Tue, May 8, 2018 at 10:09 AM, Rob Herring <robh@kernel.org> wrote:
> > The ETF input should be connected to the funnel output, and the ETF
> > output should be connected to the replicator input. The labels are wrong
> > and these got swapped:
> >
> > Warning (graph_endpoint): /soc/funnel@821000/ports/port@8/endpoint: graph connection to node '/soc/etf@825000/ports/port@1/endpoint' is not bidirectional
> > Warning (graph_endpoint): /soc/replicator@824000/ports/port@2/endpoint: graph connection to node '/soc/etf@825000/ports/port@0/endpoint' is not bidirectional
> >
> > Fixes: 7c10da373698 ("arm64: dts: qcom: Add msm8916 CoreSight components")
> > Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org>
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Cc: Andy Gross <andy.gross@linaro.org>
> > Cc: David Brown <david.brown@linaro.org>
> > Cc: linux-arm-msm@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ping. Still seeing warnings in -next for these.
>
Hi Rob,
I no longer have access to this hardware and documentation.
I am sure that Mathieu and friends will take care for verification
of this patch :-)
Regards,
Ivan
^ permalink raw reply
* Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-24 4:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Ilia Lin, vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm,
devicetree, linux-kernel
In-Reply-To: <1ec7645d-72b6-5a1a-48c3-831a3c484a0e@arm.com>
On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +static int __init qcom_cpufreq_kryo_init(void)
> > +{
> > + /*
> > + * Since the driver depends on smem and nvmem drivers, which may
> > + * return EPROBE_DEFER, all the real activity is done in the probe,
> > + * which may be defered as well. The init here is only registering
> > + * a platform device.
> > + */
> > + platform_device_register_simple("qcom-cpufreq-kryo", -1, NULL, 0);
> > + return 0;
> > +}
> > +module_init(qcom_cpufreq_kryo_init);
>
> Do you need this at all ? See below on how to eliminate the need for this.
>
> > +
> > +static struct platform_driver qcom_cpufreq_kryo_driver = {
> > + .probe = qcom_cpufreq_kryo_probe,
> > + .driver = {
> > + .name = "qcom-cpufreq-kryo",
> > + },
> > +};
> > +builtin_platform_driver(qcom_cpufreq_kryo_driver);
>
> Use builtin_platform_driver_probe and remove qcom_cpufreq_kryo_init
> or use module_platform_driver_probe if it can be module.
I agree with this, just use a single init routine to register both the driver
and device.
--
viresh
^ permalink raw reply
* Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-24 4:34 UTC (permalink / raw)
To: Sudeep Holla
Cc: Ilia Lin, vireshk, nm, sboyd, robh, mark.rutland, rjw, linux-pm,
devicetree, linux-kernel
In-Reply-To: <1ec7645d-72b6-5a1a-48c3-831a3c484a0e@arm.com>
On 23-05-18, 14:25, Sudeep Holla wrote:
> On 23/05/18 13:38, Ilia Lin wrote:
> > +config ARM_QCOM_CPUFREQ_KRYO
> > + bool "Qualcomm Kryo based CPUFreq"
> > + depends on QCOM_QFPROM
> > + depends on QCOM_SMEM
> > + select PM_OPP
> > + help
> > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
> > +
> > + If in doubt, say N.
> > +
>
> Sorry but just noticed now, any reason why this can't be module. I can't
> imagine any.
Actually I asked him to do that as cpufreq-dt itself can be compiled
in as module and this driver wasn't doing much and isn't big enough
(size wise) as well.
--
viresh
^ permalink raw reply
* [PATCH] scripts/dtc: Fixed format mismatch in fprintf
From: nixiaoming @ 2018-05-24 2:50 UTC (permalink / raw)
To: robh+dt, frowand.list; +Cc: devicetree, linux-kernel, nixiaoming
format specifier "d" need arg type "int" , but the according arg
"fdt32_to_cpu(xxx)" has type "unsigned int"
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
---
scripts/dtc/fdtdump.c | 6 +++---
scripts/dtc/flattree.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/scripts/dtc/fdtdump.c b/scripts/dtc/fdtdump.c
index 7d460a5..851bb6f 100644
--- a/scripts/dtc/fdtdump.c
+++ b/scripts/dtc/fdtdump.c
@@ -66,12 +66,12 @@ static void dump_blob(void *blob)
printf("/dts-v1/;\n");
printf("// magic:\t\t0x%x\n", fdt32_to_cpu(bph->magic));
- printf("// totalsize:\t\t0x%x (%d)\n", totalsize, totalsize);
+ printf("// totalsize:\t\t0x%x (%u)\n", totalsize, totalsize);
printf("// off_dt_struct:\t0x%x\n", off_dt);
printf("// off_dt_strings:\t0x%x\n", off_str);
printf("// off_mem_rsvmap:\t0x%x\n", off_mem_rsvmap);
- printf("// version:\t\t%d\n", version);
- printf("// last_comp_version:\t%d\n",
+ printf("// version:\t\t%u\n", version);
+ printf("// last_comp_version:\t%u\n",
fdt32_to_cpu(bph->last_comp_version));
if (version >= 2)
printf("// boot_cpuid_phys:\t0x%x\n",
diff --git a/scripts/dtc/flattree.c b/scripts/dtc/flattree.c
index 8d268fb..28da281 100644
--- a/scripts/dtc/flattree.c
+++ b/scripts/dtc/flattree.c
@@ -393,7 +393,7 @@ void dt_to_blob(FILE *f, struct dt_info *dti, int version)
padlen = 0;
if (quiet < 1)
fprintf(stderr,
- "Warning: blob size %d >= minimum size %d\n",
+ "Warning: blob size %u >= minimum size %d\n",
fdt32_to_cpu(fdt.totalsize), minsize);
}
}
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v6 4/5] arm64: dts: sdm845: Add serial console support
From: Rajendra Nayak @ 2018-05-24 2:23 UTC (permalink / raw)
To: Doug Anderson
Cc: Karthikeyan Ramasubramanian, Jonathan Corbet, Andy Gross,
David Brown, Rob Herring, Mark Rutland, Wolfram Sang, linux-doc,
linux-arm-msm, devicetree, linux-i2c, Evan Green, acourbot,
Stephen Boyd, Bjorn Andersson
In-Reply-To: <CAD=FV=WwVjMKDoL29fqdzSmi5SRQOxk_mV2=7br8HUK_hUc+XQ@mail.gmail.com>
On 05/23/2018 08:43 PM, Doug Anderson wrote:
> Rajendra,
>
> On Tue, May 22, 2018 at 11:30 PM, Rajendra Nayak <rnayak@codeaurora.org> wrote:
>>
>>
>> On 03/30/2018 10:38 PM, Karthikeyan Ramasubramanian wrote:
>>> From: Rajendra Nayak <rnayak@codeaurora.org>
>>>
>>> Add the qup uart node and geni se instance needed to
>>> support the serial console on the MTP.
>>>
>>> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>>> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
>>> ---
>>
>> Andy, is it possible to pull this one in for 4.18?
>> Sorry, I only realized we somehow missed this after looking at your pull request.
>>
>> This is the only patch that prevents linux-next from booting up my sdm845 MTP
>> to a minimal console shell.
>
> It was in Andy's tree but then got dropped. Unfortunately the clock
> bindings didn't land early enough so it's a bit difficult to land any
> device tree changes that use the clock bindings until the next kernel
> revision...
ah, okay, did not realize that. Thanks for clarifying.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Levin Du @ 2018-05-24 1:59 UTC (permalink / raw)
To: Rob Herring, Heiko Stübner
Cc: open list:ARM/Rockchip SoC..., Wayne Chou, devicetree,
Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+VBspzCaLD2Wy=fyC-S+LKGZbVsB+b+Etkx91ioXOCuQ@mail.gmail.com>
Hi all, I'd like to quote reply of Robin Murphy at
http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>
> I would suggest s/pin number/bit number in the associated GRF register/
> here. At least in this RK3328 case there's only one pin, which isn't
> numbered, and if you naively considered it pin 0 of this 'bank' you'd
> already have the wrong number. Since we're dealing with the "random
> SoC-specific controls" region of the GRF as opposed to the
> relatively-consistent and organised pinmux parts, I don't think we
> should rely on any assumptions about how things are laid out.
>
> I was initially going to suggest a more specific compatible string as
> well, but on reflection I think the generic "rockchip,gpio-syscon" for
> basic "flip this single GRF bit" functionality actually is the right way
> to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
> total related to this pin - the enable, value, and some pull controls
> (which I assume apply when the output is disabled) - if at some point in
> future we *did* want to start explicitly controlling the rest of them
> too, then would be a good time to define a separate
> "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
> for that specialised functionality, independently of this basic one.
Shall we go the generic "rockchip,gpio-syscon" way, or the specific
"rockchip,rk3328-gpio-mute" way? I prefer the former one.
The property of "gpio,syscon-dev" in gpio-syscon driver should be
documented.
Since the gpio controller is defined in the dtsi file, which inevitably
contains voodoo
register addresses. But at the board level dts file, there won't be more
register
addresses.
On 2018-05-24 3:53 AM, Rob Herring wrote:
> On Wed, May 23, 2018 at 10:12 AM, Heiko Stübner <heiko@sntech.de> wrote:
>> Hi Rob, Levin,
>>
>> sorry for being late to the party.
>>
>> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw@t-chip.com.cn wrote:
>>>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>>>
>>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>>>>> which do not belong to the general pinctrl.
>>>>>>
>>>>>> Adding gpio-syscon support makes controlling regulator or
>>>>>> LED using these special pins very easy by reusing existing
>>>>>> drivers, such as gpio-regulator and led-gpio.
>>>>>>
>>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>>>
>>>>>> Changes in v1:
>>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>>>> - Add doc rockchip,gpio-syscon.txt
>>>>>>
>>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>>>>>
>>>>>> ++++++++++++++++++++++
>>>>>>
>>>>>> drivers/gpio/gpio-syscon.c | 30
>>>>>>
>>>>>> ++++++++++++++++
>>>>>>
>>>>>> 2 files changed, 71 insertions(+)
>>>>>> create mode 100644
>>>>>>
>>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..b1b2a67
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> @@ -0,0 +1,41 @@
>>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>>>>> +- gpio-controller: Marks the device node as a gpio controller.
>>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>>>>> + the second cell is used to specify the gpio polarity:
>>>>>> + 0 = Active high,
>>>>>> + 1 = Active low.
>>>>> There's no need for this child node. Just make the parent node a gpio
>>>>> controller.
>>>>>
>>>>> Rob
>>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>>>> a
>>>> gpio controller,
>>>> like below?
>>>>
>>>> + grf: syscon at ff100000 {
>>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>>>> "syscon", "simple-mfd";
>>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>> I would disagree quite a bit here. The grf are the "general register files",
>> a bunch of registers used for quite a lot of things, and so it seems
>> among other users, also a gpio-controller for some more random pins
>> not controlled through the regular gpio controllers.
>>
>> For a more fully stocked grf, please see
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>>
>> So the gpio controller should definitly also be a subnode.
> Sigh, yes, if there are a bunch of functions needing subnodes like the
> above, then yes that makes sense. But that's not what has been
> presented. Please make some attempt at defining *all* the functions.
> An actual binding would be nice, but I'll settle for just a list of
> things. The list should have functions that have DT dependencies (like
> clocks for phys in the above) because until you do, you don't need
> child nodes.
In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
various nodes,
such as tsadc, cru, gmac2io, gmac2phy, and also pinctrl, which are not
sub nodes of
`grf`, but for reference only. The gpio-syscon node should also have
similar behavior.
They are not strongly coupled. The gpio-syscon node should be defined
outside of the
`grf` node.
>
>> The gpio in question is called "mute", so I'd think the gpio-syscon driver
>> should just define a "rockchip,rk3328-gpio-mute" compatible and contain
>> all the register voodoo in the driver itself and not define it in the dt.
> Is there really just one GPIO? If it has a defined function, then is
> it really GP? Can you control direction? I know Linus W doesn't like
> that kind of abuse of GPIO.
The "mute" pin is a output only GPIO, which is already supported by
setting flags in the gpio-syscon
driver. And yes, this pin has a defined function, but can also be used
for general purpose operation.
Thanks
Levin
^ permalink raw reply
* Re: [PATCH RFC 02/24] dt-bindings: add switch-delay property for mali-utgard
From: Qiang Yu @ 2018-05-24 1:52 UTC (permalink / raw)
To: Rob Herring
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180523170420.GA17409@rob-hp-laptop>
On Thu, May 24, 2018 at 1:04 AM, Rob Herring <robh@kernel.org> wrote:
> On Fri, May 18, 2018 at 05:27:53PM +0800, Qiang Yu wrote:
>> Signed-off-by: Qiang Yu <yuq825@gmail.com>
>> ---
>> Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> index c1f65d1dac1d..062d4bee216a 100644
>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>> @@ -58,6 +58,10 @@ Optional properties:
>> A power domain consumer specifier as defined in
>> Documentation/devicetree/bindings/power/power_domain.txt
>>
>> + - switch-delay:
>> + This value is the number of Mali clock cycles it takes to
>> + enable the power gates and turn on the power mesh.
>
> This should be implied by the SoC specific compatible string.
If so, we have to maintain a SoC-switch delay table inside the
driver. But this should be the DTS's work as it's an SoC parameter.
>
> Alternatively, can't the driver just pick a value long enough for
> everyone? Does it really vary that much, and is it timing critical?
In fact, I haven't tried setting 0xff SoC with 0xffff. I just use value
from official driver shipped with the board. But if a board need
0xffff, set to 0xff will cause it works unstable. So for setting 0xff
board to 0xffff, it may need time experiment to see if it affect
performance or stability. And need to do exp on more SoC.
Regards,
Qiang
>
> Rob
>
> P.S. Keep up the great work on this!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
From: Qiang Yu @ 2018-05-24 1:38 UTC (permalink / raw)
To: Christian König
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <c958599c-b0df-8b85-4123-daeed0fb07ac@amd.com>
On Wed, May 23, 2018 at 9:41 PM, Christian König
<christian.koenig@amd.com> wrote:
> Am 23.05.2018 um 15:13 schrieb Qiang Yu:
>>
>> On Wed, May 23, 2018 at 5:35 PM, Christian König
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>
>>> Well NAK, that brings back a callback we worked quite hard on getting rid
>>> of.
>>>
>>> It looks like the problem isn't that you need the preclose callback, but
>>> you
>>> rather seem to misunderstood how TTM works.
>>>
>>> All you need to do is to cleanup your command submission path so that the
>>> caller of lima_sched_context_queue_task() adds the resulting scheduler
>>> fence
>>> to TTMs buffer objects.
>>
>> You mean adding the finished dma fence to the buffer's reservation object
>> then
>> waiting it before unmap the buffer from GPU VM in the drm_release()'s
>> buffer
>> close callback?
>
>
> That is one possibility, but also not necessary.
>
> TTM has a destroy callback which is called from a workqueue when all fences
> on that BOs have signaled.
>
> Depending on your VM management you can use it to delay unmapping the buffer
> until it is actually not used any more.
>
>> Adding fence is done already, and I did wait it before unmap. But then
>> I see when
>> the buffer is shared between processes, the "perfect wait" is just
>> wait the fence
>> from this process's task, so it's better to also distinguish fences.
>> If so, I just think
>> why we don't just wait tasks from this process in the preclose before
>> unmap/free
>> buffer in the drm_release()?
>
>
> Well it depends on your VM management. When userspace expects that the VM
> space the BO used is reusable immediately than the TTM callback won't work.
>
> On the other hand you can just grab the list of fences on a BO and filter
> out the ones from your current process and wait for those. See
> amdgpu_sync_resv() as an example how to do that.
In current lima implementation, user space driver is responsible not unmap/free
buffer before task is complete. And VM map/unmap is not differed.
This works simple and fine except the case that user press Ctrl+C to terminate
the application which will force to close drm fd.
I'd more prefer to wait buffer fence before vm unmap and filter like
amdgpu_sync_resv() compared to implement refcount in kernel task.
But these two ways are all not as simple as preclose.
So I still don't understand why you don't want to get preclose back even
have to introduce other complicated mechanism to cover the case free/unmap
buffer before this process's task is done?
Regards,
Qiang
>
> Christian.
>
>
>>
>> Regards,
>> Qiang
>>
>>>
>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>
>>>> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b.
>>>>
>>>> lima driver need preclose to wait all task in the context
>>>> created within closing file to finish before free all the
>>>> buffer object. Otherwise pending tesk may fail and get
>>>> noisy MMU fault message.
>>>>
>>>> Move this wait to each buffer object free function can
>>>> achieve the same result but some buffer object is shared
>>>> with other file context, but we only want to wait the
>>>> closing file context's tasks. So the implementation is
>>>> not that straight forword compared to the preclose one.
>>>>
>>>> Signed-off-by: Qiang Yu <yuq825@gmail.com>
>>>> ---
>>>> drivers/gpu/drm/drm_file.c | 8 ++++----
>>>> include/drm/drm_drv.h | 23 +++++++++++++++++++++--
>>>> 2 files changed, 25 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>>>> index e394799979a6..0a43107396b9 100644
>>>> --- a/drivers/gpu/drm/drm_file.c
>>>> +++ b/drivers/gpu/drm/drm_file.c
>>>> @@ -361,8 +361,9 @@ void drm_lastclose(struct drm_device * dev)
>>>> *
>>>> * This function must be used by drivers as their
>>>> &file_operations.release
>>>> * method. It frees any resources associated with the open file, and
>>>> calls the
>>>> - * &drm_driver.postclose driver callback. If this is the last open file
>>>> for the
>>>> - * DRM device also proceeds to call the &drm_driver.lastclose driver
>>>> callback.
>>>> + * &drm_driver.preclose and &drm_driver.lastclose driver callbacks. If
>>>> this is
>>>> + * the last open file for the DRM device also proceeds to call the
>>>> + * &drm_driver.lastclose driver callback.
>>>> *
>>>> * RETURNS:
>>>> *
>>>> @@ -382,8 +383,7 @@ int drm_release(struct inode *inode, struct file
>>>> *filp)
>>>> list_del(&file_priv->lhead);
>>>> mutex_unlock(&dev->filelist_mutex);
>>>> - if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
>>>> - dev->driver->preclose)
>>>> + if (dev->driver->preclose)
>>>> dev->driver->preclose(dev, file_priv);
>>>> /* ========================================================
>>>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>>>> index d23dcdd1bd95..8d6080f97ed4 100644
>>>> --- a/include/drm/drm_drv.h
>>>> +++ b/include/drm/drm_drv.h
>>>> @@ -107,6 +107,23 @@ struct drm_driver {
>>>> */
>>>> int (*open) (struct drm_device *, struct drm_file *);
>>>> + /**
>>>> + * @preclose:
>>>> + *
>>>> + * One of the driver callbacks when a new &struct drm_file is
>>>> closed.
>>>> + * Useful for tearing down driver-private data structures
>>>> allocated in
>>>> + * @open like buffer allocators, execution contexts or similar
>>>> things.
>>>> + *
>>>> + * Since the display/modeset side of DRM can only be owned by
>>>> exactly
>>>> + * one &struct drm_file (see &drm_file.is_master and
>>>> &drm_device.master)
>>>> + * there should never be a need to tear down any modeset related
>>>> + * resources in this callback. Doing so would be a driver design
>>>> bug.
>>>> + *
>>>> + * FIXME: It is not really clear why there's both @preclose and
>>>> + * @postclose. Without a really good reason, use @postclose
>>>> only.
>>>> + */
>>>> + void (*preclose) (struct drm_device *, struct drm_file
>>>> *file_priv);
>>>> +
>>>> /**
>>>> * @postclose:
>>>> *
>>>> @@ -118,6 +135,9 @@ struct drm_driver {
>>>> * one &struct drm_file (see &drm_file.is_master and
>>>> &drm_device.master)
>>>> * there should never be a need to tear down any modeset
>>>> related
>>>> * resources in this callback. Doing so would be a driver
>>>> design
>>>> bug.
>>>> + *
>>>> + * FIXME: It is not really clear why there's both @preclose and
>>>> + * @postclose. Without a really good reason, use @postclose
>>>> only.
>>>> */
>>>> void (*postclose) (struct drm_device *, struct drm_file *);
>>>> @@ -134,7 +154,7 @@ struct drm_driver {
>>>> * state changes, e.g. in conjunction with the
>>>> :ref:`vga_switcheroo`
>>>> * infrastructure.
>>>> *
>>>> - * This is called after @postclose hook has been called.
>>>> + * This is called after @preclose and @postclose have been
>>>> called.
>>>> *
>>>> * NOTE:
>>>> *
>>>> @@ -601,7 +621,6 @@ struct drm_driver {
>>>> /* List of devices hanging off this driver with stealth attach.
>>>> */
>>>> struct list_head legacy_dev_list;
>>>> int (*firstopen) (struct drm_device *);
>>>> - void (*preclose) (struct drm_device *, struct drm_file
>>>> *file_priv);
>>>> int (*dma_ioctl) (struct drm_device *dev, void *data, struct
>>>> drm_file *file_priv);
>>>> int (*dma_quiescent) (struct drm_device *);
>>>> int (*context_dtor) (struct drm_device *dev, int context);
>>>
>>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 07/24] drm/lima: add mali 4xx GPU hardware regs
From: Qiang Yu @ 2018-05-24 0:58 UTC (permalink / raw)
To: Rob Herring
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180523172401.GC17409@rob-hp-laptop>
On Thu, May 24, 2018 at 1:24 AM, Rob Herring <robh@kernel.org> wrote:
> On Fri, May 18, 2018 at 05:27:58PM +0800, Qiang Yu wrote:
>> From: Lima Project Developers <dri-devel@lists.freedesktop.org>
>>
>> Signed-off-by: Qiang Yu <yuq825@gmail.com>
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>> ---
>> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++++++++++++++++++++++
>> 1 file changed, 304 insertions(+)
>> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>>
>> diff --git a/drivers/gpu/drm/lima/lima_regs.h b/drivers/gpu/drm/lima/lima_regs.h
>> new file mode 100644
>> index 000000000000..ea4a37d69b98
>> --- /dev/null
>> +++ b/drivers/gpu/drm/lima/lima_regs.h
>> @@ -0,0 +1,304 @@
>> +/*
>> + * Copyright (C) 2010-2017 ARM Limited. All rights reserved.
>
> I assume this came from ARM's out of tree kernel driver source. You
> should document what it was based on.
Yes, I'll comment it.
>
>> + * Copyright (C) 2017-2018 Lima Project
>
> IANAL, but is Lima Project a legal entity that can copyright things?
I heard this second time. Seems it's not a good idea to write like
this. I'll change the copyright next time.
>
>> + *
>> + * This program is free software and is provided to you under
>> + * the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation, and any use by
>> + * you of this program is subject to the terms of such GNU
>> + * licence.
>> + *
>> + * A copy of the licence is included with the program, and
>> + * can also be obtained from Free Software Foundation, Inc.,
>> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
>
> You can use SPDX tags instead.
If using SPDX, can I drop these license text? How about the copyright
text as I see SPDX header doesn't have it?
Regards,
Qiang
>
> Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 3/3] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
From: cang @ 2018-05-24 0:56 UTC (permalink / raw)
To: Rob Herring
Cc: subhashj, asutoshd, vivek.gautam, mgautam, kishon, mark.rutland,
linux-kernel, devicetree
In-Reply-To: <20180523161323.GA28074@rob-hp-laptop>
On 2018-05-24 00:13, Rob Herring wrote:
> On Wed, May 23, 2018 at 11:47:12AM +0800, Can Guo wrote:
>> Update the compatible string for UFS QMP PHY on SDM845.
>>
>> Signed-off-by: Can Guo <cang@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thank you Rob.
^ permalink raw reply
* [PATCH] arm64: dt: Update sp805 compatible string
From: Ray Jui @ 2018-05-24 0:52 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Catalin Marinas, Will Deacon,
Robin Murphy, Wim Van Sebroeck, Guenter Roeck, Wei Xu
Cc: devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui
The two sp805 binding documents 'arm,sp805.txt' and 'sp805-wdt.txt' are
consolidated into 1 ('arm,sp805.txt'), with the compatible string
consolidated to "arm,sp805", which are already used in all ARM32 dts
and most ARM64 dts files
Update the following dtsi to use the consolidated compatible string
'arm,sp805':
fsl-ls1088a.dtsi
fsl-ls208xa.dtsi
hi3660.dtsi
hi6220.dtsi
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 16 ++++++++--------
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 16 ++++++++--------
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 4 ++--
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
4 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 1c6556b..473c503 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -614,56 +614,56 @@
};
cluster1_core0_watchdog: wdt@c000000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc000000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster1_core1_watchdog: wdt@c010000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc010000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster1_core2_watchdog: wdt@c020000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc020000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster1_core3_watchdog: wdt@c030000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc030000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core0_watchdog: wdt@c100000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc100000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core1_watchdog: wdt@c110000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc110000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core2_watchdog: wdt@c120000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc120000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core3_watchdog: wdt@c130000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc130000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..5242ef9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -258,56 +258,56 @@
};
cluster1_core0_watchdog: wdt@c000000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc000000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster1_core1_watchdog: wdt@c010000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc010000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core0_watchdog: wdt@c100000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc100000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster2_core1_watchdog: wdt@c110000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc110000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster3_core0_watchdog: wdt@c200000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc200000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster3_core1_watchdog: wdt@c210000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc210000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster4_core0_watchdog: wdt@c300000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc300000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
};
cluster4_core1_watchdog: wdt@c310000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc310000 0x0 0x1000>;
clocks = <&clockgen 4 3>, <&clockgen 4 3>;
clock-names = "apb_pclk", "wdog_clk";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..dcfa3fe 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -951,7 +951,7 @@
};
watchdog0: watchdog@e8a06000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a06000 0x0 0x1000>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_OSC32K>;
@@ -959,7 +959,7 @@
};
watchdog1: watchdog@e8a07000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a07000 0x0 0x1000>;
interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&crg_ctrl HI3660_OSC32K>;
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 586b281c..beda66b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -816,7 +816,7 @@
};
watchdog0: watchdog@f8005000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xf8005000 0x0 0x1000>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ao_ctrl HI6220_WDT0_PCLK>;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH RFC 24/24] drm/lima: add makefile and kconfig
From: Qiang Yu @ 2018-05-24 0:49 UTC (permalink / raw)
To: Rob Herring
Cc: Marek Vasut, devicetree, Connor Abbott, Neil Armstrong,
Andrei Paulau, dri-devel, Vasily Khoruzhick, Simon Shields,
Erico Nunes
In-Reply-To: <20180523172627.GD17409@rob-hp-laptop>
Yeah, the list is coming longer and longer, maybe I should just use
ARM || ARM64 || COMPILE_TEST
Regards,
Qiang
On Thu, May 24, 2018 at 1:26 AM, Rob Herring <robh@kernel.org> wrote:
> On Wed, May 23, 2018 at 07:16:41PM +0200, Marek Vasut wrote:
>> On 05/18/2018 11:28 AM, Qiang Yu wrote:
>> > From: Lima Project Developers <dri-devel@lists.freedesktop.org>
>> >
>> > Signed-off-by: Qiang Yu <yuq825@gmail.com>
>> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> > Signed-off-by: Simon Shields <simon@lineageos.org>
>> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>> > ---
>> > drivers/gpu/drm/Kconfig | 2 ++
>> > drivers/gpu/drm/Makefile | 1 +
>> > drivers/gpu/drm/lima/Kconfig | 9 +++++++++
>> > drivers/gpu/drm/lima/Makefile | 19 +++++++++++++++++++
>> > 4 files changed, 31 insertions(+)
>> > create mode 100644 drivers/gpu/drm/lima/Kconfig
>> > create mode 100644 drivers/gpu/drm/lima/Makefile
>> >
>> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> > index deeefa7a1773..f00d529ee034 100644
>> > --- a/drivers/gpu/drm/Kconfig
>> > +++ b/drivers/gpu/drm/Kconfig
>> > @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
>> >
>> > source "drivers/gpu/drm/tve200/Kconfig"
>> >
>> > +source "drivers/gpu/drm/lima/Kconfig"
>> > +
>> > # Keep legacy drivers last
>> >
>> > menuconfig DRM_LEGACY
>> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> > index 50093ff4479b..aba686e41d6b 100644
>> > --- a/drivers/gpu/drm/Makefile
>> > +++ b/drivers/gpu/drm/Makefile
>> > @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
>> > obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
>> > obj-$(CONFIG_DRM_PL111) += pl111/
>> > obj-$(CONFIG_DRM_TVE200) += tve200/
>> > +obj-$(CONFIG_DRM_LIMA) += lima/
>> > diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
>> > new file mode 100644
>> > index 000000000000..4ce9ac2e8204
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/lima/Kconfig
>> > @@ -0,0 +1,9 @@
>> > +
>> > +config DRM_LIMA
>> > + tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
>> > + depends on DRM
>> > + depends on ARCH_SUNXI || ARCH_ROCKCHIP || ARCH_EXYNOS || ARCH_MESON
>>
>> You can add ARCH_ZYNQMP here too , it has Mali 400 MP2.
>
> Better yet, just drop them all rather than continually adding to the
> list.
>
> But if you keep it, add '|| COMPILE_TEST'.
>
> Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 12/24] drm/lima: add GP related functions
From: Qiang Yu @ 2018-05-24 0:38 UTC (permalink / raw)
To: Marek Vasut
Cc: Simon Shields, devicetree, Connor Abbott, Neil Armstrong,
Andrei Paulau, dri-devel, Vasily Khoruzhick, Erico Nunes
In-Reply-To: <7b42a0c2-3737-327c-3829-0c322497b317@denx.de>
On Thu, May 24, 2018 at 1:12 AM, Marek Vasut <marex@denx.de> wrote:
> On 05/18/2018 11:28 AM, Qiang Yu wrote:
>> GP is a processor for OpenGL vertex shader
>> processing.
>>
>> Signed-off-by: Qiang Yu <yuq825@gmail.com>
>
> [...]
>
>> +int lima_gp_init(struct lima_ip *ip)
>> +{
>> + struct lima_device *dev = ip->dev;
>> + int err;
>> +
>> + lima_gp_print_version(ip);
>> +
>> + ip->data.async_reset = false;
>> + lima_gp_soft_reset_async(ip);
>> + err = lima_gp_soft_reset_async_wait(ip);
>> + if (err)
>> + return err;
>> +
>> + err = devm_request_irq(dev->dev, ip->irq, lima_gp_irq_handler, 0,
>> + lima_ip_name(ip), ip);
>
> IRQF_SHARED, since there are designs (like zynqmp) where there is only
> one IRQ line for the entire GPU.
Right, will add this flag.
Regards,
Qiang
>
>> + if (err) {
>> + dev_err(dev->dev, "gp %s fail to request irq\n",
>> + lima_ip_name(ip));
>> + return err;
>> + }
>> +
>> + return 0;
>> +}
>
>
> [...]
>
> --
> Best regards,
> Marek Vasut
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox