* [PATCH 5/6] ARM: configs: bcm_defconfig: enable bcm59056 regulator support
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Enable BCM59056 MFD and regulator drivers to manage voltage
regulators on BCM281xx platforms.
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
arch/arm/configs/bcm_defconfig | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 2519d6d..35752cc 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -79,6 +79,13 @@ CONFIG_HW_RANDOM=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
# CONFIG_HWMON is not set
+CONFIG_MFD_BCM59056=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
+CONFIG_REGULATOR_USERSPACE_CONSUMER=y
+CONFIG_REGULATOR_BCM59056=y
+
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
--
1.8.4
^ permalink raw reply related
* [PATCH 4/6] regulator: add bcm59056 regulator driver
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a regulator driver for the BCM59056 PMU voltage regulators.
The driver supports LDOs and DCDCs in normal mode only. There is
no support for low-power mode or power sequencing.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++++++++++++++
3 files changed, 454 insertions(+)
create mode 100644 drivers/regulator/bcm59056-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..e09c9ea5 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -139,6 +139,14 @@ config REGULATOR_AS3722
AS3722 PMIC. This will enable support for all the software
controllable DCDC/LDO regulators.
+config REGULATOR_BCM59056
+ tristate "Broadcom BCM59056 PMU Regulators"
+ depends on MFD_BCM59056
+ help
+ This driver provides support for the voltage regulators on the
+ BCM59056 PMU. This will enable support for the software
+ controllable LDO/Switching regulators.
+
config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..bb65035 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
+obj-$(CONFIG_REGULATOR_BCM59056) += bcm59056-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
diff --git a/drivers/regulator/bcm59056-regulator.c b/drivers/regulator/bcm59056-regulator.c
new file mode 100644
index 0000000..3fbc1d5
--- /dev/null
+++ b/drivers/regulator/bcm59056-regulator.c
@@ -0,0 +1,445 @@
+/*
+ * Broadcom BCM59056 regulator driver
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mfd/bcm59056.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
+#include <linux/slab.h>
+
+/* Register defs */
+#define BCM59056_RFLDOPMCTRL1 0x60
+#define BCM59056_IOSR1PMCTRL1 0x7a
+#define BCM59056_IOSR2PMCTRL1 0x7c
+#define BCM59056_CSRPMCTRL1 0x7e
+#define BCM59056_SDSR1PMCTRL1 0x82
+#define BCM59056_SDSR2PMCTRL1 0x86
+#define BCM59056_MSRPMCTRL1 0x8a
+#define BCM59056_VSRPMCTRL1 0x8e
+#define BCM59056_REG_ENABLE BIT(7)
+
+#define BCM59056_RFLDOCTRL 0x96
+#define BCM59056_CSRVOUT1 0xc0
+#define BCM59056_LDO_VSEL_MASK GENMASK(5, 3)
+#define BCM59056_SR_VSEL_MASK GENMASK(5, 0)
+
+/* LDO regulator IDs */
+#define BCM59056_REG_RFLDO 0
+#define BCM59056_REG_CAMLDO1 1
+#define BCM59056_REG_CAMLDO2 2
+#define BCM59056_REG_SIMLDO1 3
+#define BCM59056_REG_SIMLDO2 4
+#define BCM59056_REG_SDLDO 5
+#define BCM59056_REG_SDXLDO 6
+#define BCM59056_REG_MMCLDO1 7
+#define BCM59056_REG_MMCLDO2 8
+#define BCM59056_REG_AUDLDO 9
+#define BCM59056_REG_MICLDO 10
+#define BCM59056_REG_USBLDO 11
+#define BCM59056_REG_VIBLDO 12
+
+/* DCDC regulator IDs */
+#define BCM59056_REG_CSR 13
+#define BCM59056_REG_IOSR1 14
+#define BCM59056_REG_IOSR2 15
+#define BCM59056_REG_MSR 16
+#define BCM59056_REG_SDSR1 17
+#define BCM59056_REG_SDSR2 18
+#define BCM59056_REG_VSR 19
+
+#define BCM59056_NUM_REGS 20
+
+#define BCM59056_REG_IS_LDO(n) (n < BCM59056_REG_CSR)
+
+struct bcm59056_board {
+ struct regulator_init_data *bcm59056_pmu_init_data[BCM59056_NUM_REGS];
+};
+
+/* LDO group A: supported voltages in microvolts */
+static const unsigned int ldo_a_table[] = {
+ 1200000, 1800000, 2500000, 2700000, 2800000,
+ 2900000, 3000000, 3300000,
+};
+
+/* LDO group C: supported voltages in microvolts */
+static const unsigned int ldo_c_table[] = {
+ 3100000, 1800000, 2500000, 2700000, 2800000,
+ 2900000, 3000000, 3300000,
+};
+
+/* DCDC group CSR: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_csr_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 50, 10000),
+ REGULATOR_LINEAR_RANGE(1360000, 51, 55, 20000),
+ REGULATOR_LINEAR_RANGE(900000, 56, 63, 0),
+};
+
+/* DCDC group IOSR1: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_iosr1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 51, 10000),
+ REGULATOR_LINEAR_RANGE(1500000, 52, 52, 0),
+ REGULATOR_LINEAR_RANGE(1800000, 53, 53, 0),
+ REGULATOR_LINEAR_RANGE(900000, 54, 63, 0),
+};
+
+/* DCDC group SDSR1: supported voltages in microvolts */
+static const struct regulator_linear_range dcdc_sdsr1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(860000, 2, 50, 10000),
+ REGULATOR_LINEAR_RANGE(1340000, 51, 51, 0),
+ REGULATOR_LINEAR_RANGE(900000, 52, 63, 0),
+};
+
+struct bcm59056_info {
+ const char *name;
+ const char *vin_name;
+ u8 n_voltages;
+ const unsigned int *volt_table;
+ u8 n_linear_ranges;
+ const struct regulator_linear_range *linear_ranges;
+};
+
+#define BCM59056_REG_TABLE(_name, _table) \
+ { \
+ .name = #_name, \
+ .n_voltages = ARRAY_SIZE(_table), \
+ .volt_table = _table, \
+ }
+
+#define BCM59056_REG_RANGES(_name, _ranges) \
+ { \
+ .name = #_name, \
+ .n_linear_ranges = ARRAY_SIZE(_ranges), \
+ .linear_ranges = _ranges, \
+ }
+
+static struct bcm59056_info bcm59056_regs[] = {
+ BCM59056_REG_TABLE(rfldo, ldo_a_table),
+ BCM59056_REG_TABLE(camldo1, ldo_c_table),
+ BCM59056_REG_TABLE(camldo2, ldo_c_table),
+ BCM59056_REG_TABLE(simldo1, ldo_a_table),
+ BCM59056_REG_TABLE(simldo2, ldo_a_table),
+ BCM59056_REG_TABLE(sdldo, ldo_c_table),
+ BCM59056_REG_TABLE(sdxldo, ldo_a_table),
+ BCM59056_REG_TABLE(mmcldo1, ldo_a_table),
+ BCM59056_REG_TABLE(mmcldo2, ldo_a_table),
+ BCM59056_REG_TABLE(audldo, ldo_a_table),
+ BCM59056_REG_TABLE(micldo, ldo_a_table),
+ BCM59056_REG_TABLE(usbldo, ldo_a_table),
+ BCM59056_REG_TABLE(vibldo, ldo_c_table),
+ BCM59056_REG_RANGES(csr, dcdc_csr_ranges),
+ BCM59056_REG_RANGES(iosr1, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(iosr2, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(msr, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
+ BCM59056_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
+ BCM59056_REG_RANGES(vsr, dcdc_iosr1_ranges),
+};
+
+struct bcm59056_reg {
+ struct regulator_desc *desc;
+ struct bcm59056 *mfd;
+ struct regulator_dev **rdev;
+ struct bcm59056_info **info;
+};
+
+static int bcm59056_get_vsel_register(int id)
+{
+ if (BCM59056_REG_IS_LDO(id))
+ return BCM59056_RFLDOCTRL + id;
+ else
+ return BCM59056_CSRVOUT1 + (id - BCM59056_REG_CSR) * 3;
+}
+
+static int bcm59056_get_enable_register(int id)
+{
+ int reg = 0;
+
+ if (BCM59056_REG_IS_LDO(id))
+ reg = BCM59056_RFLDOPMCTRL1 + id * 2;
+ else
+ switch (id) {
+ case BCM59056_REG_CSR:
+ reg = BCM59056_CSRPMCTRL1;
+ break;
+ case BCM59056_REG_IOSR1:
+ reg = BCM59056_IOSR1PMCTRL1;
+ break;
+ case BCM59056_REG_IOSR2:
+ reg = BCM59056_IOSR2PMCTRL1;
+ break;
+ case BCM59056_REG_MSR:
+ reg = BCM59056_MSRPMCTRL1;
+ break;
+ case BCM59056_REG_SDSR1:
+ reg = BCM59056_SDSR1PMCTRL1;
+ break;
+ case BCM59056_REG_SDSR2:
+ reg = BCM59056_SDSR2PMCTRL1;
+ break;
+ };
+
+ return reg;
+}
+
+static unsigned int bcm59056_get_mode(struct regulator_dev *dev)
+{
+ return REGULATOR_MODE_NORMAL;
+}
+
+static int bcm59056_set_mode(struct regulator_dev *dev, unsigned int mode)
+{
+ if (mode == REGULATOR_MODE_NORMAL)
+ return 0;
+ else
+ return -EINVAL;
+}
+
+static struct regulator_ops bcm59056_ops_ldo = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .set_mode = bcm59056_set_mode,
+ .get_mode = bcm59056_get_mode,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_table,
+ .map_voltage = regulator_map_voltage_iterate,
+};
+
+static struct regulator_ops bcm59056_ops_dcdc = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .set_mode = bcm59056_set_mode,
+ .get_mode = bcm59056_get_mode,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+};
+
+#define BCM59056_MATCH(_name, _id) \
+ { \
+ .name = #_name, \
+ .driver_data = (void *)&bcm59056_regs[BCM59056_REG_##_id], \
+ }
+
+static struct of_regulator_match bcm59056_matches[] = {
+ BCM59056_MATCH(rfldo, RFLDO),
+ BCM59056_MATCH(camldo1, CAMLDO1),
+ BCM59056_MATCH(camldo2, CAMLDO2),
+ BCM59056_MATCH(simldo1, SIMLDO1),
+ BCM59056_MATCH(simldo2, SIMLDO2),
+ BCM59056_MATCH(sdldo, SDLDO),
+ BCM59056_MATCH(sdxldo, SDXLDO),
+ BCM59056_MATCH(mmcldo1, MMCLDO1),
+ BCM59056_MATCH(mmcldo2, MMCLDO2),
+ BCM59056_MATCH(audldo, AUDLDO),
+ BCM59056_MATCH(micldo, MICLDO),
+ BCM59056_MATCH(usbldo, USBLDO),
+ BCM59056_MATCH(vibldo, VIBLDO),
+ BCM59056_MATCH(csr, CSR),
+ BCM59056_MATCH(iosr1, IOSR1),
+ BCM59056_MATCH(iosr2, IOSR2),
+ BCM59056_MATCH(msr, MSR),
+ BCM59056_MATCH(sdsr1, SDSR1),
+ BCM59056_MATCH(sdsr2, SDSR2),
+ BCM59056_MATCH(vsr, VSR),
+};
+
+static struct bcm59056_board *bcm59056_parse_dt_reg_data(
+ struct platform_device *pdev,
+ struct of_regulator_match **bcm59056_reg_matches)
+{
+ struct bcm59056_board *data;
+ struct device_node *np, *regulators;
+ struct of_regulator_match *matches = bcm59056_matches;
+ int count = ARRAY_SIZE(bcm59056_matches);
+ int idx = 0;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(&pdev->dev, "failed to allocate regulator board data\n");
+ return NULL;
+ }
+
+ np = of_node_get(pdev->dev.parent->of_node);
+ regulators = of_get_child_by_name(np, "regulators");
+ if (!regulators) {
+ dev_err(&pdev->dev, "regulator node not found\n");
+ return NULL;
+ }
+
+ ret = of_regulator_match(&pdev->dev, regulators, matches, count);
+ of_node_put(regulators);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Error parsing regulator init data: %d\n",
+ ret);
+ return NULL;
+ }
+
+ *bcm59056_reg_matches = matches;
+
+ for (idx = 0; idx < count; idx++) {
+ if (!matches[idx].init_data || !matches[idx].of_node)
+ continue;
+
+ data->bcm59056_pmu_init_data[idx] = matches[idx].init_data;
+ }
+
+ return data;
+}
+
+static int bcm59056_probe(struct platform_device *pdev)
+{
+ struct bcm59056 *bcm59056 = dev_get_drvdata(pdev->dev.parent);
+ struct bcm59056_board *pmu_data = NULL;
+ struct bcm59056_reg *pmu;
+ struct regulator_config config = { };
+ struct bcm59056_info *info;
+ struct regulator_init_data *reg_data;
+ struct regulator_dev *rdev;
+ struct of_regulator_match *bcm59056_reg_matches = NULL;
+ int i;
+
+ if (bcm59056->dev->of_node)
+ pmu_data = bcm59056_parse_dt_reg_data(pdev,
+ &bcm59056_reg_matches);
+
+ if (!pmu_data) {
+ dev_err(&pdev->dev, "Platform data not found\n");
+ return -EINVAL;
+ }
+
+ pmu = devm_kzalloc(&pdev->dev, sizeof(*pmu), GFP_KERNEL);
+ if (!pmu) {
+ dev_err(&pdev->dev, "Memory allocation failed for pmu\n");
+ return -ENOMEM;
+ }
+
+ pmu->mfd = bcm59056;
+
+ platform_set_drvdata(pdev, pmu);
+
+ pmu->desc = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct regulator_desc), GFP_KERNEL);
+ if (!pmu->desc) {
+ dev_err(&pdev->dev, "Memory alloc fails for desc\n");
+ return -ENOMEM;
+ }
+
+ pmu->info = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct bcm59056_info *), GFP_KERNEL);
+ if (!pmu->info) {
+ dev_err(&pdev->dev, "Memory alloc fails for info\n");
+ return -ENOMEM;
+ }
+
+ pmu->rdev = devm_kzalloc(&pdev->dev, BCM59056_NUM_REGS *
+ sizeof(struct regulator_dev *), GFP_KERNEL);
+ if (!pmu->rdev) {
+ dev_err(&pdev->dev, "Memory alloc fails for rdev\n");
+ return -ENOMEM;
+ }
+
+ info = bcm59056_regs;
+
+ for (i = 0; i < BCM59056_NUM_REGS; i++, info++) {
+ reg_data = pmu_data->bcm59056_pmu_init_data[i];
+
+ /*
+ * Regulator API handles empty constraints but not NULL
+ * constraints
+ */
+ if (!reg_data)
+ continue;
+
+ /* Register the regulators */
+ pmu->info[i] = info;
+
+ pmu->desc[i].name = info->name;
+ pmu->desc[i].supply_name = info->vin_name;
+ pmu->desc[i].id = i;
+ pmu->desc[i].volt_table = info->volt_table;
+ pmu->desc[i].n_voltages = info->n_voltages;
+ pmu->desc[i].linear_ranges = info->linear_ranges;
+ pmu->desc[i].n_linear_ranges = info->n_linear_ranges;
+
+ if (BCM59056_REG_IS_LDO(i)) {
+ pmu->desc[i].ops = &bcm59056_ops_ldo;
+ pmu->desc[i].vsel_mask = BCM59056_LDO_VSEL_MASK;
+ } else {
+ pmu->desc[i].ops = &bcm59056_ops_dcdc;
+ pmu->desc[i].vsel_mask = BCM59056_SR_VSEL_MASK;
+ }
+
+ pmu->desc[i].vsel_reg = bcm59056_get_vsel_register(i);
+ pmu->desc[i].enable_is_inverted = true;
+ pmu->desc[i].enable_mask = BCM59056_REG_ENABLE;
+ pmu->desc[i].enable_reg = bcm59056_get_enable_register(i);
+ pmu->desc[i].type = REGULATOR_VOLTAGE;
+ pmu->desc[i].owner = THIS_MODULE;
+
+ config.dev = bcm59056->dev;
+ config.init_data = reg_data;
+ config.driver_data = pmu;
+ config.regmap = bcm59056->regmap;
+
+ if (bcm59056_reg_matches)
+ config.of_node = bcm59056_reg_matches[i].of_node;
+
+ rdev = devm_regulator_register(&pdev->dev, &pmu->desc[i],
+ &config);
+ if (IS_ERR(rdev)) {
+ dev_err(bcm59056->dev,
+ "failed to register %s regulator\n",
+ pdev->name);
+ return PTR_ERR(rdev);
+ }
+
+ pmu->rdev[i] = rdev;
+ }
+
+ return 0;
+}
+
+static struct platform_driver bcm59056_regulator_driver = {
+ .driver = {
+ .name = "bcm59056-pmu",
+ .owner = THIS_MODULE,
+ },
+ .probe = bcm59056_probe,
+};
+
+static int __init bcm59056_regulator_init(void)
+{
+ return platform_driver_register(&bcm59056_regulator_driver);
+}
+subsys_initcall(bcm59056_regulator_init);
+
+static void __exit bcm59056_regulator_exit(void)
+{
+ platform_driver_unregister(&bcm59056_regulator_driver);
+}
+module_exit(bcm59056_regulator_exit);
+
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_DESCRIPTION("BCM59056 voltage regulator driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:bcm59056-regulator");
--
1.8.4
^ permalink raw reply related
* [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a driver for the BCM59056 PMU multi-function device. The driver
initially supports regmap initialization and instantiation of the
voltage regulator device function of the PMU.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
drivers/mfd/Kconfig | 8 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/bcm59056.c | 119 +++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/bcm59056.h | 35 +++++++++++++
4 files changed, 163 insertions(+)
create mode 100644 drivers/mfd/bcm59056.c
create mode 100644 include/linux/mfd/bcm59056.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..36e96c2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,14 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_BCM59056
+ bool "Broadcom BCM59056 PMU"
+ select MFD_CORE
+ select REGMAP_I2C
+ depends on I2C=y
+ help
+ Support for the BCM59056 PMU from Broadcom
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5aea5ef..8d7e110 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
obj-$(CONFIG_MFD_SM501) += sm501.o
obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o
+obj-$(CONFIG_MFD_BCM59056) += bcm59056.o
obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C) += cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI) += cros_ec_spi.o
diff --git a/drivers/mfd/bcm59056.c b/drivers/mfd/bcm59056.c
new file mode 100644
index 0000000..f193bfb
--- /dev/null
+++ b/drivers/mfd/bcm59056.c
@@ -0,0 +1,119 @@
+/*
+ * Broadcom BCM59056 PMU
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/mfd/bcm59056.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+static struct mfd_cell bcm59056s[] = {
+ {
+ .name = "bcm59056-pmu",
+ },
+};
+
+static const struct regmap_config bcm59056_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM59056_MAX_REGISTER - 1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm59056_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct bcm59056 *bcm59056;
+ int chip_id = id->driver_data;
+ int ret = 0;
+
+ bcm59056 = devm_kzalloc(&i2c->dev, sizeof(*bcm59056), GFP_KERNEL);
+ if (!bcm59056)
+ return -ENOMEM;
+
+ i2c_set_clientdata(i2c, bcm59056);
+ bcm59056->dev = &i2c->dev;
+ bcm59056->i2c_client = i2c;
+ bcm59056->id = chip_id;
+
+ bcm59056->regmap = devm_regmap_init_i2c(i2c, &bcm59056_regmap_config);
+ if (IS_ERR(bcm59056->regmap)) {
+ ret = PTR_ERR(bcm59056->regmap);
+ dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = mfd_add_devices(bcm59056->dev, -1,
+ bcm59056s, ARRAY_SIZE(bcm59056s),
+ NULL, 0, NULL);
+ if (ret < 0)
+ dev_err(&i2c->dev, "mfd_add_devices failed: %d\n", ret);
+
+ return ret;
+}
+
+static int bcm59056_i2c_remove(struct i2c_client *i2c)
+{
+ struct bcm59056 *bcm59056 = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(bcm59056->dev);
+
+ return 0;
+}
+
+static const struct of_device_id bcm59056_of_match[] = {
+ { .compatible = "brcm,bcm59056", .data = (void *)BCM59056 },
+ { }
+};
+
+static const struct i2c_device_id bcm59056_i2c_id[] = {
+ { "bcm59056", BCM59056 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, bcm59056_i2c_id);
+
+static struct i2c_driver bcm59056_i2c_driver = {
+ .driver = {
+ .name = "bcm59056",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(bcm59056_of_match),
+ },
+ .probe = bcm59056_i2c_probe,
+ .remove = bcm59056_i2c_remove,
+ .id_table = bcm59056_i2c_id,
+};
+
+static int __init bcm59056_init(void)
+{
+ return i2c_add_driver(&bcm59056_i2c_driver);
+}
+subsys_initcall(bcm59056_init);
+
+static void __exit bcm59056_exit(void)
+{
+ i2c_del_driver(&bcm59056_i2c_driver);
+}
+module_exit(bcm59056_exit);
+
+MODULE_AUTHOR("Matt Porter <mporter@linaro.org>");
+MODULE_DESCRIPTION("BCM59056 multi-function driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:bcm59056");
diff --git a/include/linux/mfd/bcm59056.h b/include/linux/mfd/bcm59056.h
new file mode 100644
index 0000000..967395d
--- /dev/null
+++ b/include/linux/mfd/bcm59056.h
@@ -0,0 +1,35 @@
+/*
+ * Broadcom BCM59056 PMU
+ *
+ * Copyright 2014 Linaro Limited
+ * Author: Matt Porter <mporter@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __LINUX_MFD_BCM59056_H
+#define __LINUX_MFD_BCM59056_H
+
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/regmap.h>
+
+/* chip id */
+#define BCM59056 0
+
+/* max register address */
+#define BCM59056_MAX_REGISTER 0xe8
+
+/* bcm59056 chip access */
+struct bcm59056 {
+ struct device *dev;
+ struct i2c_client *i2c_client;
+ struct regmap *regmap;
+ unsigned int id;
+};
+
+#endif /* __LINUX_MFD_BCM59056_H */
--
1.8.4
^ permalink raw reply related
* [PATCH 2/6] regulator: add bcm59056 pmu DT binding
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Add a DT binding for the BCM59056 PMU. The binding inherits from
the generic regulator bindings.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
.../devicetree/bindings/regulator/bcm59056.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
diff --git a/Documentation/devicetree/bindings/regulator/bcm59056.txt b/Documentation/devicetree/bindings/regulator/bcm59056.txt
new file mode 100644
index 0000000..bf6b633
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/bcm59056.txt
@@ -0,0 +1,37 @@
+BCM59056 Power Management Unit
+
+Required properties:
+- compatible: "brcm,bcm59056"
+- reg: I2C slave address
+- interrupts: interrupt for the PMU. Generic interrupt client node bindings
+ are described in interrupt-controller/interrupts.txt
+- regulators: This is the list of child nodes that specify the regulator
+ initialization data for defined regulators. Generic regulator bindings
+ are described in regulator/regulator.txt.
+
+ The valid regulator-compatible values are:
+ rfldo, camldo1, camldo2, simldo1, simlso2, sdldo, sdxldo,
+ mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+
+Example:
+ pmu: bcm59056 at 8 {
+ compatible = "brcm,bcm59056";
+ reg = <0x08>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rfldo_reg: regulator at 0 {
+ reg = <0>;
+ regulator-compatible = "rfldo";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ...
+ };
+ };
--
1.8.4
^ permalink raw reply related
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391516352-32359-1-git-send-email-mporter@linaro.org>
Voltage regulators are needed very early due to deferred probe
being incompatible with built-in USB gadget drivers. In order to
have the PMU driver available before USB UDC, make i2c available
during subsys_initcall.
Signed-off-by: Matt Porter <mporter@linaro.org>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
Reviewed-by: Markus Mayer <markus.mayer@linaro.org>
---
drivers/i2c/busses/i2c-bcm-kona.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-kona.c b/drivers/i2c/busses/i2c-bcm-kona.c
index 18a74a6..bfd4056 100644
--- a/drivers/i2c/busses/i2c-bcm-kona.c
+++ b/drivers/i2c/busses/i2c-bcm-kona.c
@@ -901,7 +901,19 @@ static struct platform_driver bcm_kona_i2c_driver = {
.probe = bcm_kona_i2c_probe,
.remove = bcm_kona_i2c_remove,
};
-module_platform_driver(bcm_kona_i2c_driver);
+
+static int __init bcm_kona_i2c_init_driver(void)
+{
+ return platform_driver_register(&bcm_kona_i2c_driver);
+}
+/* PMU access is needed early so use subsys init */
+subsys_initcall(bcm_kona_i2c_init_driver);
+
+static void __exit bcm_kona_i2c_exit_driver(void)
+{
+ platform_driver_unregister(&bcm_kona_i2c_driver);
+}
+module_exit(bcm_kona_i2c_exit_driver);
MODULE_AUTHOR("Tim Kryger <tkryger@broadcom.com>");
MODULE_DESCRIPTION("Broadcom Kona I2C Driver");
--
1.8.4
^ permalink raw reply related
* [PATCH 0/6] BCM59056 PMU regulator support
From: Matt Porter @ 2014-02-04 12:19 UTC (permalink / raw)
To: linux-arm-kernel
The BCM59056 is a multi-function power management unit used with the
BCM281xx family of SoCs. This series adds an MFD and voltage regulator
driver to support the BCM59056. The bcm28155-ap DT support is updated
to enable use of regulators on the otg and sdhci peripherals.
Matt Porter (6):
i2c: bcm-kona: register with subsys_initcall
regulator: add bcm59056 pmu DT binding
mfd: add bcm59056 pmu driver
regulator: add bcm59056 regulator driver
ARM: configs: bcm_defconfig: enable bcm59056 regulator support
ARM: dts: add bcm59056 pmu support and enable for bcm28155-ap
.../devicetree/bindings/regulator/bcm59056.txt | 37 ++
arch/arm/boot/dts/bcm28155-ap.dts | 41 ++
arch/arm/boot/dts/bcm59056.dtsi | 158 ++++++++
arch/arm/configs/bcm_defconfig | 7 +
drivers/i2c/busses/i2c-bcm-kona.c | 14 +-
drivers/mfd/Kconfig | 8 +
drivers/mfd/Makefile | 1 +
drivers/mfd/bcm59056.c | 119 ++++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/bcm59056-regulator.c | 445 +++++++++++++++++++++
include/linux/mfd/bcm59056.h | 35 ++
12 files changed, 873 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/regulator/bcm59056.txt
create mode 100644 arch/arm/boot/dts/bcm59056.dtsi
create mode 100644 drivers/mfd/bcm59056.c
create mode 100644 drivers/regulator/bcm59056-regulator.c
create mode 100644 include/linux/mfd/bcm59056.h
--
1.8.4
^ permalink raw reply
* [RFC] dt-bindings: configuration of parent clocks and clock frequency
From: Marek Szyprowski @ 2014-02-04 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140201030614.9977.80501@quantum>
Hello,
On 2014-02-01 04:06, Mike Turquette wrote:
> Quoting Sylwester Nawrocki (2014-01-21 04:48:43)
> > 5. Similarly to the regulator bindings the clock names could be appended
> > to name of a DT property:
> >
> > [clk_name]-assigned-clock-parent = <...>;
> > [clk_name]-assigned-clock-rate = <...>;
>
> I have always been partial to the way that the reg framework does its
> [reg_name]-supply. We could shorten it to something like:
>
> [clk-name]-asn-parent = ....
> [clk-name]-asn-rate = ...
>
> This is actually the format that was discussed at the ARM kernel summit
> IIRC.
I think that "[clk-name]-clk-parent" and "[clk-name]-clk-rate" will be a bit
more descriptive names instead of quite ambiguous "asn".
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* arm64: kernel panic in paging_init()
From: Catalin Marinas @ 2014-02-04 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391460649.13327.51.camel@deneb.redhat.com>
On Mon, Feb 03, 2014 at 08:50:49PM +0000, Mark Salter wrote:
> I'm seeing the following panic in paging init. This is on the foundation
> model with a modified dtb memory node which has a non section-aligned
> bank:
> memory at 80000000 {
> device_type = "memory";
> reg = <0x00000000 0x80000000 0 0x20000000>,
> <0x00000000 0xa0300000 0 0x1fd00000>;
> };
>
> I only see this with 64k pagesize configured. What happens is the
> non section-aligned bank causes alloc_init_pte() to allocate a page
> for the new pte from the end of the first bank (the failing address
> 0xfffffe001fff0000 [0x9fff0000 phys]). This should be a valid page
> since it was mapped during the create_mapping() call for the first
> memory bank. A flush_tlb_all() added to the end of create_mapping()
> makes the panic go away so I think the problem is something stale
> cached before the page with the failing address was mapped.
I think it goes like this:
head.S maps enough memory to get started but using 64K pages rather than
512M sections with a single pgd entry and several ptes. This never gets
to the end of the first block (just up to KERNEL_END).
create_mapping() realises it can do a 512M section mapping, overriding
the original table pgd entry with a block one. The memblock limit is set
correctly PGDIR_SIZE but create_mapping, when it replaces the table pgd
with a block one doesn't do any TLB invalidation.
So I wouldn't do a TLB invalidation all the time but only when the old
pmd was set. Please give the patch below a try, I only compiled it (I'll
add some text afterwards):
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f557ebbe7013..f8dc7e8fce6f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -203,10 +203,18 @@ static void __init alloc_init_pmd(pud_t *pud, unsigned long addr,
do {
next = pmd_addr_end(addr, end);
/* try section mapping first */
- if (((addr | next | phys) & ~SECTION_MASK) == 0)
+ if (((addr | next | phys) & ~SECTION_MASK) == 0) {
+ pmd_t old_pmd =*pmd;
set_pmd(pmd, __pmd(phys | prot_sect_kernel));
- else
+ /*
+ * Check for previous table entries created during
+ * boot (__create_page_tables) and flush them.
+ */
+ if (!pmd_none(old_pmd))
+ flush_tlb_all();
+ } else {
alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys));
+ }
phys += next - addr;
} while (pmd++, addr = next, addr != end);
}
Thanks.
--
Catalin
^ permalink raw reply related
* [PATCH v2 5/5] of: document bindings for reserved-memory nodes
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-1-git-send-email-m.szyprowski@samsung.com>
From: Grant Likely <grant.likely@linaro.org>
Reserved memory nodes allow for the reservation of static (fixed
address) regions, or dynamically allocated regions for a specific
purpose.
[joshc: Based on binding document proposed (in non-patch form) here:
http://lkml.kernel.org/g/20131030134702.19B57C402A0 at trevor.secretlab.ca
adapted to support #memory-region-cells]
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
.../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++++++++++
1 file changed, 138 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
new file mode 100644
index 000000000000..a606ce90c9c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -0,0 +1,138 @@
+*** Reserved memory regions ***
+
+Reserved memory is specified as a node under the /reserved-memory node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions. Such memory regions are usually designed for
+the special usage by various device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory node
+---------------------
+#address-cells, #size-cells (required) - standard definition
+ - Should use the same values as the root node
+#memory-region-cells (required) - dictates number of cells used in the child
+ nodes memory-region specifier
+ranges (required) - standard definition
+ - Should be empty
+
+/reserved-memory/ child nodes
+-----------------------------
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a 'reg' property to
+specify a specific range of reserved memory, or a 'size' property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+address (@<address>) should be appended to the name if the node is a
+static allocation.
+
+Properties:
+Requires either a) or b) below.
+a) static allocation
+ reg (required) - standard definition
+b) dynamic allocation
+ size (required) - length based on parent's #size-cells
+ - Size in bytes of memory to reserve.
+ alignment (optional) - length based on parent's #size-cells
+ - Address boundary for alignment of allocation.
+ alloc-ranges (optional) - prop-encoded-array (address, length pairs).
+ - Specifies regions of memory that are
+ acceptable to allocate from.
+
+If both reg and size are present, then the reg property takes precedence
+and size is ignored.
+
+Additional properties:
+compatible (optional) - standard definition
+ - may contain the following strings:
+ - shared-dma-pool: This indicates a region of memory meant to be
+ used as a shared pool of DMA buffers for a set of devices. It can
+ be used by an operating system to instanciate the necessary pool
+ management subsystem if necessary.
+ - vendor specific string in the form <vendor>,[<device>-]<usage>
+no-map (optional) - empty property
+ - Indicates the operating system must not create a virtual mapping
+ of the region as part of its standard mapping of system memory,
+ nor permit speculative access to it under any circumstances other
+ than under the control of the device driver using the region.
+reusable (optional) - empty property
+ - The operating system can use the memory in this region with the
+ limitation that the device driver(s) owning the region need to be
+ able to reclaim it back. Typically that means that the operating
+ system can use that region to store volatile or cached data that
+ can be otherwise regenerated or migrated elsewhere.
+
+Linux implementation note:
+- If a "linux,cma-default" property is present, then Linux will use the
+ region for the default pool of the contiguous memory allocator.
+
+Device node references to reserved memory
+-----------------------------------------
+Regions in the /reserved-memory node may be referenced by other device
+nodes by adding a memory-region property to the device node.
+
+memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
+
+Example
+-------
+This example defines 3 contiguous regions are defined for Linux kernel:
+one default of all device drivers (named linux,cma at 72000000 and 64MiB in size),
+one dedicated to the framebuffer device (named framebuffer at 78000000, 8MiB), and
+one for multimedia processing (named multimedia-memory at 77000000, 64MiB).
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory {
+ reg = <0x40000000 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ #memory-region-cells = <0>;
+ size = <0x4000000>;
+ alignment = <0x2000>;
+ linux,cma-default;
+ };
+
+ display_reserved: framebuffer at 78000000 {
+ #memory-region-cells = <0>;
+ reg = <0x78000000 0x800000>;
+ };
+
+ multimedia_reserved: multimedia at 77000000 {
+ compatible = "acme,multimedia-memory";
+ #memory-region-cells = <1>;
+ reg = <0x77000000 0x4000000>;
+ };
+ };
+
+ /* ... */
+
+ fb0: video at 12300000 {
+ memory-region = <&display_reserved>;
+ /* ... */
+ };
+
+ scaler: scaler at 12500000 {
+ memory-region = <&multimedia_reserved 0xdeadbeef>;
+ /* ... */
+ };
+
+ codec: codec at 12600000 {
+ memory-region = <&multimedia_reserved 0xfeebdaed>;
+ /* ... */
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/5] ARM: init: add support for reserved memory defined by device tree
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-1-git-send-email-m.szyprowski@samsung.com>
Enable reserved memory initialization from device tree.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mm/init.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 804d61566a53..ebafdb479410 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -17,6 +17,7 @@
#include <linux/nodemask.h>
#include <linux/initrd.h>
#include <linux/of_fdt.h>
+#include <linux/of_reserved_mem.h>
#include <linux/highmem.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
@@ -323,6 +324,8 @@ void __init arm_memblock_init(struct meminfo *mi,
if (mdesc->reserve)
mdesc->reserve();
+ early_init_dt_scan_reserved_mem();
+
/*
* reserve memory for DMA contigouos allocations,
* must come from DMA area inside low memory
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/5] drivers: of: implement reserved-memory handling for cma
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-1-git-send-email-m.szyprowski@samsung.com>
From: Josh Cartwright <joshc@codeaurora.org>
Add support for handling 'shared-dma-pool' reserved-memory nodes using
Contiguous Memory Allocator driver.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/of/Kconfig | 7 ++++
drivers/of/Makefile | 1 +
drivers/of/of_reserved_mem_cma.c | 75 ++++++++++++++++++++++++++++++++++++++
3 files changed, 83 insertions(+)
create mode 100644 drivers/of/of_reserved_mem_cma.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 7ac330473ec9..5dd3a80910d2 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -81,6 +81,13 @@ config OF_RESERVED_MEM
help
Helpers to allow for reservation of memory regions
+config OF_RESERVED_MEM_CMA
+ depends on OF_RESERVED_MEM
+ depends on DMA_CMA
+ def_bool y
+ help
+ Helpers for reserving memory regions for DMA use
+
config OF_RESERVED_MEM_DMA
depends on OF_RESERVED_MEM
depends on HAVE_GENERIC_DMA_COHERENT
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 6142227ca854..49b9078637b8 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_OF_RESERVED_MEM_CMA) += of_reserved_mem_cma.o
obj-$(CONFIG_OF_RESERVED_MEM_DMA) += of_reserved_mem_dma.o
diff --git a/drivers/of/of_reserved_mem_cma.c b/drivers/of/of_reserved_mem_cma.c
new file mode 100644
index 000000000000..601d80655102
--- /dev/null
+++ b/drivers/of/of_reserved_mem_cma.c
@@ -0,0 +1,75 @@
+/*
+ * Device tree based initialization code for DMA reserved regions.
+ *
+ * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski <m.szyprowski@samsung.com>
+ * Author: Josh Cartwright <joshc@codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
+#include <linux/mm.h>
+#include <linux/sizes.h>
+#include <linux/mm_types.h>
+#include <linux/dma-contiguous.h>
+#include <linux/of_reserved_mem.h>
+
+static void rmem_cma_device_init(struct reserved_mem *rmem,
+ struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct cma *cma = rmem->priv;
+ dev_set_cma_area(dev, cma);
+}
+
+static const struct reserved_mem_ops rmem_cma_ops = {
+ .device_init = rmem_cma_device_init,
+};
+
+static int __init rmem_cma_setup(struct reserved_mem *rmem,
+ unsigned long node,
+ const char *uname)
+{
+ struct cma *cma;
+ int err;
+
+ if (!of_get_flat_dt_prop(node, "reusable", NULL))
+ return -EINVAL;
+
+ err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
+ if (!err)
+ goto out_done;
+
+ rmem->base = 0;
+ err = of_parse_flat_dt_size(node, uname, &rmem->size);
+ if (err)
+ goto out_err;
+
+out_done:
+ err = dma_contiguous_reserve_area(rmem->size, rmem->base, 0,
+ &cma);
+ if (err) {
+ pr_err("Reserved memory: unable to setup CMA region\n");
+ return err;
+ }
+
+ if (of_get_flat_dt_prop(node, "linux,cma-default", NULL))
+ dma_contiguous_set_default(cma);
+
+ rmem->ops = &rmem_cma_ops;
+ rmem->priv = cma;
+
+ return 0;
+out_err:
+ pr_err("Reseved memory: malformed node '%s'.\n", uname);
+ return err;
+}
+RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/5] drivers: of: implement reserved-memory handling for dma
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-1-git-send-email-m.szyprowski@samsung.com>
From: Josh Cartwright <joshc@codeaurora.org>
Add support for handling 'shared-dma-pool' reserved-memory nodes using
dma exclusive driver (dma_alloc_coherent()).
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/of/Kconfig | 7 ++++
drivers/of/Makefile | 1 +
drivers/of/of_reserved_mem_dma.c | 78 ++++++++++++++++++++++++++++++++++++++
3 files changed, 86 insertions(+)
create mode 100644 drivers/of/of_reserved_mem_dma.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index aba13df56f3a..7ac330473ec9 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -81,4 +81,11 @@ config OF_RESERVED_MEM
help
Helpers to allow for reservation of memory regions
+config OF_RESERVED_MEM_DMA
+ depends on OF_RESERVED_MEM
+ depends on HAVE_GENERIC_DMA_COHERENT
+ def_bool y
+ help
+ Helpers for reserving memory regions for DMA use
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ed9660adad77..6142227ca854 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
+obj-$(CONFIG_OF_RESERVED_MEM_DMA) += of_reserved_mem_dma.o
diff --git a/drivers/of/of_reserved_mem_dma.c b/drivers/of/of_reserved_mem_dma.c
new file mode 100644
index 000000000000..53a4cac6084a
--- /dev/null
+++ b/drivers/of/of_reserved_mem_dma.c
@@ -0,0 +1,78 @@
+/*
+ * Device tree based initialization code for DMA reserved regions.
+ *
+ * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski <m.szyprowski@samsung.com>
+ * Author: Josh Cartwright <joshc@codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+#include <linux/memblock.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
+#include <linux/mm.h>
+#include <linux/sizes.h>
+#include <linux/mm_types.h>
+#include <linux/dma-mapping.h>
+#include <linux/of_reserved_mem.h>
+
+static void rmem_dma_device_init(struct reserved_mem *rmem,
+ struct device *dev,
+ struct of_phandle_args *args)
+{
+ dma_declare_coherent_memory(dev, rmem->base, rmem->base,
+ rmem->size, DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+}
+
+static void rmem_dma_device_release(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ dma_release_declared_memory(dev);
+}
+
+static const struct reserved_mem_ops rmem_dma_ops = {
+ .device_init = rmem_dma_device_init,
+ .device_release = rmem_dma_device_release,
+};
+
+static int __init rmem_dma_setup(struct reserved_mem *rmem,
+ unsigned long node,
+ const char *uname)
+{
+ int err;
+
+ if (of_get_flat_dt_prop(node, "reusable", NULL))
+ return -EINVAL;
+
+ err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
+ if (!err)
+ goto out_done;
+
+ err = of_parse_flat_dt_size(node, uname, &rmem->size);
+ if (err)
+ goto out_err;
+
+ rmem->base = memblock_alloc_base(rmem->size, PAGE_SIZE,
+ MEMBLOCK_ALLOC_ANYWHERE);
+ memblock_free(rmem->base, rmem->size);
+
+out_done:
+ rmem->ops = &rmem_dma_ops;
+ pr_info("Reserved memory: created DMA memory pool at %pa, size %ld MiB\n",
+ &rmem->base, (unsigned long)rmem->size / SZ_1M);
+
+ return memblock_remove(rmem->base, rmem->size);
+
+out_err:
+ pr_err("Reserved memory: unable to setup '%s' memory region for DMA.\n",
+ uname);
+ return err;
+}
+RESERVEDMEM_OF_DECLARE(dma, "shared-dma-pool", rmem_dma_setup);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391515773-6112-1-git-send-email-m.szyprowski@samsung.com>
This patch adds device tree support for contiguous and reserved memory
regions defined in device tree.
Large memory blocks can be reliably reserved only during early boot.
This must happen before the whole memory management subsystem is
initialized, because we need to ensure that the given contiguous blocks
are not yet allocated by kernel. Also it must happen before kernel
mappings for the whole low memory are created, to ensure that there will
be no mappings (for reserved blocks) or mapping with special properties
can be created (for CMA blocks). This all happens before device tree
structures are unflattened, so we need to get reserved memory layout
directly from fdt.
Later, those reserved memory regions are assigned to devices on each
device structure initialization.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
[joshc: rework to implement new DT binding, provide mechanism for
plugging in new reserved-memory node handlers via
RESERVEDMEM_OF_DECLARE]
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
[mszyprow: little code cleanup]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/of/Kconfig | 6 +
drivers/of/Makefile | 1 +
drivers/of/of_reserved_mem.c | 219 +++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 7 ++
include/asm-generic/vmlinux.lds.h | 11 ++
include/linux/of_reserved_mem.h | 62 +++++++++++
6 files changed, 306 insertions(+)
create mode 100644 drivers/of/of_reserved_mem.c
create mode 100644 include/linux/of_reserved_mem.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index c6973f101a3e..aba13df56f3a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -75,4 +75,10 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_RESERVED_MEM
+ depends on HAVE_MEMBLOCK
+ def_bool y
+ help
+ Helpers to allow for reservation of memory regions
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index efd05102c405..ed9660adad77 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
new file mode 100644
index 000000000000..f17cd56e68d9
--- /dev/null
+++ b/drivers/of/of_reserved_mem.c
@@ -0,0 +1,219 @@
+/*
+ * Device tree based initialization code for reserved memory.
+ *
+ * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Author: Marek Szyprowski <m.szyprowski@samsung.com>
+ * Author: Josh Cartwright <joshc@codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+#include <linux/memblock.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/of_platform.h>
+#include <linux/mm.h>
+#include <linux/sizes.h>
+#include <linux/of_reserved_mem.h>
+
+#define MAX_RESERVED_REGIONS 16
+static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
+static int reserved_mem_count;
+
+int __init of_parse_flat_dt_reg(unsigned long node, const char *uname,
+ phys_addr_t *base, phys_addr_t *size)
+{
+ unsigned long len;
+ __be32 *prop;
+
+ prop = of_get_flat_dt_prop(node, "reg", &len);
+ if (!prop)
+ return -EINVAL;
+
+ if (len < (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32)) {
+ pr_err("Reserved memory: invalid reg property in '%s' node.\n",
+ uname);
+ return -EINVAL;
+ }
+
+ *base = dt_mem_next_cell(dt_root_addr_cells, &prop);
+ *size = dt_mem_next_cell(dt_root_size_cells, &prop);
+ return 0;
+}
+
+int __init of_parse_flat_dt_size(unsigned long node, const char *uname,
+ phys_addr_t *size)
+{
+ unsigned long len;
+ __be32 *prop;
+
+ prop = of_get_flat_dt_prop(node, "size", &len);
+ if (!prop)
+ return -EINVAL;
+
+ if (len < dt_root_size_cells * sizeof(__be32)) {
+ pr_err("Reserved memory: invalid size property in '%s' node.\n",
+ uname);
+ return -EINVAL;
+ }
+
+ *size = dt_mem_next_cell(dt_root_size_cells, &prop);
+ return 0;
+}
+
+static int __init rmem_default_early_setup(struct reserved_mem *rmem,
+ unsigned long node,
+ const char *uname)
+{
+ int err;
+
+ if (of_get_flat_dt_prop(node, "compatible", NULL))
+ return -EINVAL;
+
+ err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
+ if (err)
+ return err;
+
+ if (of_get_flat_dt_prop(node, "no-map", NULL))
+ err = memblock_remove(rmem->base, rmem->size);
+ else
+ err = memblock_reserve(rmem->base, rmem->size);
+
+ if (err == 0)
+ pr_info("Reserved memory: found '%s', memory base %pa, size %ld MiB\n",
+ uname, &rmem->base, (unsigned long)rmem->size / SZ_1M);
+
+ return err;
+}
+
+static const struct of_device_id rmem_default_id
+ __used __section(__reservedmem_of_table_end) = {
+ .data = rmem_default_early_setup,
+};
+
+static int __init fdt_scan_reserved_mem(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
+ extern const struct of_device_id __reservedmem_of_table[];
+ const struct of_device_id *id;
+ const char *status;
+
+ if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
+ pr_err("Reserved memory: not enough space all defined regions.\n");
+ return -ENOSPC;
+ }
+
+ status = of_get_flat_dt_prop(node, "status", NULL);
+ if (status && strcmp(status, "okay") != 0)
+ return 0;
+
+ /*
+ * The default handler above ensures this section is terminated with a
+ * id whose compatible string is empty
+ */
+ for (id = __reservedmem_of_table; id <= &rmem_default_id; id++) {
+ reservedmem_of_init_fn initfn = id->data;
+ const char *compat = id->compatible;
+
+ if (compat[0] && !of_flat_dt_is_compatible(node, compat))
+ continue;
+
+ if (initfn(rmem, node, uname) == 0) {
+ pr_info("Reserved memory: created %s node, compatible id %s\n",
+ uname, compat);
+ rmem->name = uname;
+ reserved_mem_count++;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+static struct reserved_mem *find_rmem(struct device_node *np)
+{
+ const char *name;
+ unsigned int i;
+
+ name = kbasename(np->full_name);
+
+ for (i = 0; i < reserved_mem_count; i++)
+ if (strcmp(name, reserved_mem[i].name) == 0)
+ return &reserved_mem[i];
+
+ return NULL;
+}
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given device
+ *
+ * This function assign memory region pointed by "memory-region" device tree
+ * property to the given device.
+ */
+void of_reserved_mem_device_init(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct reserved_mem *rmem;
+ struct of_phandle_args s;
+ unsigned int i;
+
+ for (i = 0; of_parse_phandle_with_args(np, "memory-region",
+ "#memory-region-cells", i, &s) == 0; i++) {
+
+ rmem = find_rmem(s.np);
+ if (!rmem || !rmem->ops || !rmem->ops->device_init) {
+ of_node_put(s.np);
+ continue;
+ }
+
+ rmem->ops->device_init(rmem, dev, &s);
+ dev_info(dev, "assigned reserved memory node %s\n",
+ rmem->name);
+ of_node_put(s.np);
+ break;
+ }
+}
+
+/**
+ * of_reserved_mem_device_release() - release reserved memory device structures
+ *
+ * This function releases structures allocated for memory region handling for
+ * the given device.
+ */
+void of_reserved_mem_device_release(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct reserved_mem *rmem;
+ struct of_phandle_args s;
+ unsigned int i;
+
+ for (i = 0; of_parse_phandle_with_args(np, "memory-region",
+ "#memory-region-cells", i, &s) == 0; i++) {
+
+ rmem = find_rmem(s.np);
+ if (rmem && rmem->ops && rmem->ops->device_release)
+ rmem->ops->device_release(rmem, dev);
+
+ of_node_put(s.np);
+ }
+}
+
+/**
+ * early_init_dt_scan_reserved_mem() - create reserved memory regions
+ *
+ * This function grabs memory from early allocator for device exclusive use
+ * defined in device tree structures. It should be called by arch specific code
+ * once the early allocator (memblock) has been activated and all other
+ * subsystems have already allocated/reserved memory.
+ */
+void __init early_init_dt_scan_reserved_mem(void)
+{
+ of_scan_flat_dt_by_path("/reserved-memory", fdt_scan_reserved_mem,
+ NULL);
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1daebefa..3df0b1826e8b 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -21,6 +21,7 @@
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
#include <linux/platform_device.h>
const struct of_device_id of_default_bus_match_table[] = {
@@ -220,6 +221,8 @@ static struct platform_device *of_platform_device_create_pdata(
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
+ of_reserved_mem_device_init(&dev->dev);
+
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
@@ -227,6 +230,7 @@ static struct platform_device *of_platform_device_create_pdata(
if (of_device_add(dev) != 0) {
platform_device_put(dev);
+ of_reserved_mem_device_release(&dev->dev);
return NULL;
}
@@ -282,6 +286,8 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
else
of_device_make_bus_id(&dev->dev);
+ of_reserved_mem_device_init(&dev->dev);
+
/* Allow the HW Peripheral ID to be overridden */
prop = of_get_property(node, "arm,primecell-periphid", NULL);
if (prop)
@@ -308,6 +314,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
return dev;
err_free:
+ of_reserved_mem_device_release(&dev->dev);
amba_device_put(dev);
return NULL;
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bc2121fa9132..f10f64fcc815 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -167,6 +167,16 @@
#define CLK_OF_TABLES()
#endif
+#ifdef CONFIG_OF_RESERVED_MEM
+#define RESERVEDMEM_OF_TABLES() \
+ . = ALIGN(8); \
+ VMLINUX_SYMBOL(__reservedmem_of_table) = .; \
+ *(__reservedmem_of_table) \
+ *(__reservedmem_of_table_end)
+#else
+#define RESERVEDMEM_OF_TABLES()
+#endif
+
#define KERNEL_DTB() \
STRUCT_ALIGN(); \
VMLINUX_SYMBOL(__dtb_start) = .; \
@@ -490,6 +500,7 @@
TRACE_SYSCALLS() \
MEM_DISCARD(init.rodata) \
CLK_OF_TABLES() \
+ RESERVEDMEM_OF_TABLES() \
CLKSRC_OF_TABLES() \
KERNEL_DTB() \
IRQCHIP_OF_MATCH_TABLE()
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
new file mode 100644
index 000000000000..41f43828e1db
--- /dev/null
+++ b/include/linux/of_reserved_mem.h
@@ -0,0 +1,62 @@
+#ifndef __OF_RESERVED_MEM_H
+#define __OF_RESERVED_MEM_H
+
+struct cma;
+struct platform_device;
+struct of_phandle_args;
+struct reserved_mem_ops;
+
+struct reserved_mem {
+ const char *name;
+ const struct reserved_mem_ops *ops;
+ phys_addr_t base;
+ phys_addr_t size;
+ void *priv;
+};
+
+struct reserved_mem_ops {
+ void (*device_init)(struct reserved_mem *rmem,
+ struct device *dev,
+ struct of_phandle_args *args);
+ void (*device_release)(struct reserved_mem *rmem,
+ struct device *dev);
+};
+
+typedef int (*reservedmem_of_init_fn)(struct reserved_mem *rmem,
+ unsigned long node, const char *uname);
+
+#ifdef CONFIG_OF_RESERVED_MEM
+void of_reserved_mem_device_init(struct device *dev);
+void of_reserved_mem_device_release(struct device *dev);
+void early_init_dt_scan_reserved_mem(void);
+
+int of_parse_flat_dt_reg(unsigned long node, const char *uname,
+ phys_addr_t *base, phys_addr_t *size);
+int of_parse_flat_dt_size(unsigned long node, const char *uname,
+ phys_addr_t *size);
+
+#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
+ static const struct of_device_id __reservedmem_of_table_##name \
+ __used __section(__reservedmem_of_table) \
+ = { .compatible = compat, \
+ .data = (init == (reservedmem_of_init_fn)NULL) ? \
+ init : init }
+
+#else
+static inline void of_reserved_mem_device_init(struct device *dev) { }
+
+static inline
+void of_reserved_mem_device_release(struct device *dev) { }
+
+static inline void early_init_dt_scan_reserved_mem(void) { }
+
+#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
+ static const struct of_device_id __reservedmem_of_table_##name \
+ __attribute__((unused)) \
+ = { .compatible = compat, \
+ .data = (init == (reservedmem_of_init_fn)NULL) ? \
+ init : init }
+
+#endif
+
+#endif /* __OF_RESERVED_MEM_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/5] reserved-memory regions/CMA in devicetree, again
From: Marek Szyprowski @ 2014-02-04 12:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi all!
This is an updated version of the second attempt to add basic support
for dynamic allocation of memory reserved regions defined in device
tree.
The initial code for this feature were posted here [1], merged as commit
9d8eab7af79cb4ce2de5de39f82c455b1f796963 ("drivers: of: add
initialization code for dma reserved memory") and later reverted by
commit 1931ee143b0ab72924944bc06e363d837ba05063. For more information,
see [2]. Finally a new bindings has been proposed [3] and Josh
Cartwright a few days ago prepared some code which implements those
bindings [4]. This finally pushed me again to find some time to finish
this task and review the code. Josh agreed to give me the ownership of
this series to continue preparing them for mainline inclusion.
For more information please refer to the changlelog below.
[1]: http://lkml.kernel.org/g/1377527959-5080-1-git-send-email-m.szyprowski at samsung.com
[2]: http://lkml.kernel.org/g/1381476448-14548-1-git-send-email-m.szyprowski at samsung.com
[3]: http://lkml.kernel.org/g/20131030134702.19B57C402A0 at trevor.secretlab.ca
[4]: http://thread.gmane.org/gmane.linux.documentation/19579
Changelog:
v2:
- removed copying of the node name
- split shared-dma-pool handling into separate files (one for CMA and one
for dma_declare_coherent based implementations) for making the code easier
to understand
- added support for AMBA devices, changed prototypes to use struct decice
instead of struct platform_device
- renamed some functions to better match other names used in drivers/of/
- restructured the rest of the code a bit for better readability
- added 'reusable' property to exmaple linux,cma node in documentation
- exclusive dma (dma_coherent) is used for only handling 'shared-dma-pool'
regions without 'reusable' property and CMA is used only for handling
'shared-dma-pool' regions with 'reusable' property.
v1: http://thread.gmane.org/gmane.linux.documentation/19579
- initial version prepared by Josh Cartwright
Summary:
Grant Likely (1):
of: document bindings for reserved-memory nodes
Josh Cartwright (2):
drivers: of: implement reserved-memory handling for dma
drivers: of: implement reserved-memory handling for cma
Marek Szyprowski (2):
drivers: of: add initialization code for reserved memory
ARM: init: add support for reserved memory defined by device tree
.../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++
arch/arm/mm/init.c | 3 +
drivers/of/Kconfig | 20 ++
drivers/of/Makefile | 3 +
drivers/of/of_reserved_mem.c | 219 ++++++++++++++++++++
drivers/of/of_reserved_mem_cma.c | 75 +++++++
drivers/of/of_reserved_mem_dma.c | 78 +++++++
drivers/of/platform.c | 7 +
include/asm-generic/vmlinux.lds.h | 11 +
include/linux/of_reserved_mem.h | 62 ++++++
10 files changed, 616 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
create mode 100644 drivers/of/of_reserved_mem.c
create mode 100644 drivers/of/of_reserved_mem_cma.c
create mode 100644 drivers/of/of_reserved_mem_dma.c
create mode 100644 include/linux/of_reserved_mem.h
--
1.7.9.5
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-04 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4524393.8AzpATULMB@wuerfel>
On Tue, Feb 04, 2014 at 10:09:44AM +0000, Arnd Bergmann wrote:
> On Monday 03 February 2014 22:17:44 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 07:31:31PM +0000, Arnd Bergmann wrote:
> > > Let's try to come up with nomenclature so we can talk about this better
> > >
> > > The ioport_resource is in "logical I/O space", which is a Linux fiction,
> > > it goes from 0 to IO_SPACE_LIMIT (2MB on ARM) and is mapped into "virtual
> > > I/O space", which start at (void __iomem *)PCI_IO_VIRT_BASE.
> > >
> > > Each PCI domain can have its own "bus I/O aperture", which is typically
> > > between 0x1000 and 0xffff and reflects the address that is used in PCI
> > > transactions and in BARs.
> >
> > Actually, the bus I/O aperture can start from 0x0000 if you are talking about
> > PCI bus addresses.
>
> Right.
>
> > > The aperture here reflects the subset of the
> > > 4GB bus I/O space that is actually mapped into a CPU visible "physical
> > > I/O aperture" using an inbound mapping of the host bridge. The physical
> > > I/O aperture in turn gets mapped to the virtual I/O space using
> > > pci_ioremap_io.
> >
> > Agree.
> >
> > > The difference between a bus I/O address and a logical
> > > I/O address is stored in the io_offset.
> >
> > Not exactly. If that would be true that means that for an I/O range that
> > start at bus I/O address zero but physical I/O apperture starts at
> > 0x40000000 the io_offset is zero. For me, the io_offset should be 0x40000000.
>
> That's not how we do it on any of the existing host controllers.
> Typically the io_offset is zero for the first one, and may be
> either zero for all the others (meaning BARs get > 64KB values
> for secondary buses) or between 64KB and 2MB (meaning each bus
> starts at I/O port number 0).
In that case it is probably worth to rename my variable into phys_io_offset.
I need to go back over my driver code. My assumptions were probably wrong
wrt to meaning of the io_offset.
>
> > Let me see if I can summarise this correctly, using only CPU addresses:
> >
> > 0x0000 - IO_SPACE_LIMIT <- logical I/O address
> > 0xPPPPPPPP - 0xPPPPPPPP+IO_SIZE <- physical address for PCI I/O space
> > 0xVVVVVVVV - 0xVVVVVVVV+IO_SPACE_LIMIT <- virtual address for I/O
> >
> > The io_offset then is 0xPPPPPPPP - logical I/O address. At least that is
> > the intent of the io_offset variable that I introduced in pci_host_bridge.
>
> That is highly confusing then, because we already have something called
> io_offset with a different meaning. I would call 0xPPPPPPPP the io_phys_base
> if I had to come up with a variable name for it.
>
> > The bus I/O address is generated by the host bridge, I think we can ignore
> > it here as it tends to confuse the message.
>
> No, it's important because the PCI core code has to transform between
> bus I/O address and logical I/O address when accessing the BARs.
>
> > > So much for basic definitions. When a device driver calls pci_request_region,
> > > the port number it sees is the bus I/O port number adjusted using the
> > > io_offset to turn it into a logical I/O port number, which should
> > > always be within the host bridge window, which in turn is a subset
> > > of the ioport_resource.
> >
> > My understanding is that device drivers all user port numbers that are logical
> > I/O numbers, so no io_offset needs to be applied here. It is only when one
> > wants to access the port, that the translation happens. First, inb or outb
> > will add the PCI_IO_VIRT_BASE to generate the virtual address, the MMU will
> > then convert that address to physical address and the host bridge will
> > then translate the physical address into bus address.
>
> This is correct. The bus I/O number is not visible to the device driver,
> but it is what you put into the 'ranges' property in DT, and it gets
> used during PCI resource scanning.
>
>
> > > > And that is why the code in probe.c has been added to deal with that. It is
> > > > too early to do the adjustments here as all we have is the list of resources
> > > > and that might get culled by the architecture fixup code. Remembering the
> > > > io_offset will happen once the pci_host_bridge gets created, and the resources
> > > > are then adjusted.
> > >
> > > So you want to register an incorrect I/O resource first and then
> > > have it fixed up later, rather than registering the correct
> > > one from the start as everyone else?
> >
> > The incorrect I/O resource is added to a temporary list of resources, it has not
> > been attached yet to the list of windows in the bridge. What gets added is the
> > I/O resource as described if it would be an ordinary resource.
>
> I'm not completely sure I'm following here, but let's work out the
> other things first, this will probably get clearer then.
>
> > > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > > > > index 6e34498..16febae 100644
> > > > > > --- a/drivers/pci/probe.c
> > > > > > +++ b/drivers/pci/probe.c
> > > > > > @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> > > > > > list_for_each_entry_safe(window, n, resources, list) {
> > > > > > list_move_tail(&window->list, &bridge->windows);
> > > > > > res = window->res;
> > > > > > + /*
> > > > > > + * IO resources are stored in the kernel with a CPU start
> > > > > > + * address of zero. Adjust the data accordingly and remember
> > > > > > + * the offset
> > > > > > + */
> > > > > > + if (resource_type(res) == IORESOURCE_IO) {
> > > > > > + bridge->io_offset = res->start;
> > > > > > + res->end -= res->start;
> > > > > > + window->offset -= res->start;
> > > > > > + res->start = 0;
> > > > > > + }
> >
> > Here, we correct for the fact that IORESOURCE_IO is not a normal resource, because Linux wants
> > a logical I/O as start and end address, not the physical CPU address. We adjust to that and
> > remember the offset.
>
> But the offset (phys_base) doesn't actually matter to the PCI core or
> the driver. Why save it?
Because I need it later for the host bridge ATR setup.
>
> > > > > > offset = window->offset;
> > > > > > if (res->flags & IORESOURCE_BUS)
> > > > >
> > > > > Won't this break all existing host bridges?
> > > >
> > > > I am not sure. I believe not, due to what I've explained earlier, but you might be right.
> > > >
> > > > The adjustment happens before the resource is added to the host bridge windows and translates
> > > > it from MMIO range into IO range.
> > >
> > > AFAICT, the resource_type of the resource you register above should be
> > > IORESOURCE_MEM, so you are not actually matching it here.
> >
> > No, all resources are added here. For IORESOURCE_IO we do an adjustment.
>
> But there should never be an IORESOURCE_IO resource structure that is
> not in IO space, i.e. within ioport_resource. Doing an "adjustment"
> is not an operation defined on this structure. What I meant above is that
> the pci range parser gets this right and gives you a resource that looks
> like { .flags = IORESOURCE_MEM, .start = phys_base, .end = phys_base +
> size - 1}, while the resource we want to register is { .flags = IORESOURCE_IO,
> .start = log_base, .end = log_base + size -1}. In the of_pci_range struct for
> the I/O space, the "pci_space" is IORESOURCE_IO (for the pci_addr), while the
> "flags" are IORESOURCE_MEM, to go along with the cpu_addr.
The pci range parser gives me a range with .flags = IORESOURCE_IO for IO space. It
does not convert it to IORESOURCE_MEM. Hence the need for adjustment.
Best regards,
Liviu
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
^ permalink raw reply
* [Patch v4 1/2] dmaengine: add Qualcomm BAM dma driver
From: Lars-Peter Clausen @ 2014-02-04 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391468687-4347-2-git-send-email-agross@codeaurora.org>
On 02/04/2014 12:04 AM, Andy Gross wrote:
[...]
> +static int bam_dma_remove(struct platform_device *pdev)
> +{
> + struct bam_device *bdev = platform_get_drvdata(pdev);
> + u32 i;
> +
> + dma_async_device_unregister(&bdev->common);
> + of_dma_controller_free(pdev->dev.of_node);
The controller should first be removed from the of lookup table, then free
the device.
> +
> + /* mask all interrupts for this execution environment */
> + writel_relaxed(0, bdev->regs + BAM_IRQ_SRCS_MSK_EE(bdev->ee));
You still need to free the interrupt to make this race free, especially on a
multi-processor system. free_irq() acts as a synchronization point that
makes sure that interrupt handler has finished running and that no new
interrupt handlers are being run after this point. Just masking the
interrupt in the control register does not provide these guarantees.
> +
> + for (i = 0; i < bdev->num_channels; i++) {
> + bam_dma_terminate_all(&bdev->channels[i]);
> + tasklet_kill(&bdev->channels[i].vc.task);
> + }
> +
> + tasklet_kill(&bdev->task);
> +
> + clk_disable_unprepare(bdev->bamclk);
> +
> + return 0;
> +}
[...]
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204110922.GA27975@e106497-lin.cambridge.arm.com>
On Tuesday 04 February 2014 11:09:22 Liviu Dudau wrote:
> On Tue, Feb 04, 2014 at 08:44:36AM +0000, Arnd Bergmann wrote:
> > Well, I/O space never starts at physical zero in reality, so it is
> > broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
> > the problem of I/O spaces that are not memory mapped, which is
> > actually quite rare (x86, ia64, some rare powerpc bridges, and possibly
> > Alpha). The norm is that if you have I/O space, it is memory mapped
> > and you don't need GENERIC_IOMAP. I think most of the architectures
> > selecting GENERIC_IOMAP have incorrectly copied that from x86.
>
> If you are talking about CPU addresses for I/O space, then you are (mostly?) right.
> I've seen some code in powerpc that tries to handle the case where I/O starts at zero.
>
> For MMIO, yes, it would be crazy to start at CPU address zero. But,
> the ioport_map takes a port number, and those do start at zero, right?
What I meant is that asm-generic/io.h assumes that the I/O ports are
mapped at /virtual/ address zero, which is even more crazy, since that
is normally in user space. Sorry for confusing it with physical address
zero.
Now the GENERIC_IOMAP uses a similar fiction by defining that virtual
address token 0x10000-0x1ffff are used to access I/O space when calling
inb/outb, but that is something you only need to do when you have
no memory mapped I/O port.
Some older ARM platforms (PXA for instance) also defined the I/O space
to start at virtual address zero, and use a per-bus io_offset that was
equal to the ioremapped I/O window. This actually works, but it means
that the logical port numbers are all high, and you have to set
IO_SPACE_LIMIT to ULONG_MAX, and it breaks horribly for any driver that
tries to store a port number in a type that is shorter than 'unsigned
long'. We definitely don't want to do this for new code.
> > > My main concern with the existing API is the requirement to have a subsys_initcall
> > > in your host bridge or mach code, due to the way the initialisation is done (you
> > > need the DT code to probe your driver, but you cannot start the scanning of the
> > > PCI bus until the arch code is initialised, so it gets deferred via
> > > subsys_initcall when it calls pci_common_init). I bet that if one tries to
> > > instantiate a Tegra PCI host bridge controller on a Marvell platform things will
> > > break pretty quickly (random example here).
> >
> > I'm not following here. All the new host controller drivers should
> > be platform drivers that only bind to the host devices in DT
> > that are present. Both mvebu and tegra use a normal "module_platform_driver"
> > for initialization, not a "subsys_initcall".
>
> I was actually looking at mach-dove, I thought that was Marvell as well.
mach-dove is going away soon, it will get merged into mach-mvebu and
then use drivers/pci/host/pci-mvebu.c
> But both mvebu and tegra call pci_common_init_dev. The busnr gets assigned based on
> the registration order. I wonder if any of the host bridge code copes with having
> assigned a bus number other than zero for its "root bus".
I think all "new" host bridges now use nr_controllers=1, which means
that you always start at but number zero and use PCI domain if
you have multiple independent root bridges.
> >
> > Right. I guess we can support both interfaces on ARM32 for the forseeable
> > future (renaming the new one) and just change the existing implementation
> > to update the bitmap. Any cross-platform host controller driver would
> > have to use the new interface however.
>
> OK, I can try to add the function to my patch. Call it pci_ioremap_iores?
Sounds ok, I can't think of anything better at least.
Arnd
^ permalink raw reply
* [PATCH v4 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-04 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391513453-21140-3-git-send-email-ivan.khoronzhuk@ti.com>
Sorry I forgot to add
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
On 02/04/2014 01:30 PM, Ivan Khoronzhuk wrote:
> This patch provides bindings for the 64-bit timer in the KeyStone
> architecture devices. The timer can be configured as a general-purpose 64-bit
> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or independently
> (unchained mode) of each other.
>
> It is global timer is a free running up-counter and can generate interrupt
> when the counter reaches preset counter values.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> .../bindings/timer/ti,keystone-timer.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> new file mode 100644
> index 0000000..5fbe361
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
> @@ -0,0 +1,29 @@
> +* Device tree bindings for Texas instruments Keystone timer
> +
> +This document provides bindings for the 64-bit timer in the KeyStone
> +architecture devices. The timer can be configured as a general-purpose 64-bit
> +timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> +timers, each half can operate in conjunction (chain mode) or independently
> +(unchained mode) of each other.
> +
> +It is global timer is a free running up-counter and can generate interrupt
> +when the counter reaches preset counter values.
> +
> +Documentation:
> +http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
> +
> +Required properties:
> +
> +- compatible : should be "ti,keystone-timer".
> +- reg : specifies base physical address and count of the registers.
> +- interrupts : interrupt generated by the timer.
> +- clocks : the clock feeding the timer clock.
> +
> +Example:
> +
> +timer at 22f0000 {
> + compatible = "ti,keystone-timer";
> + reg = <0x022f0000 0x80>;
> + interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clktimer15>;
> +};
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v4 1/3] clocksource: timer-keystone: introduce clocksource driver for Keystone
From: Ivan Khoronzhuk @ 2014-02-04 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391513453-21140-2-git-send-email-ivan.khoronzhuk@ti.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Santosh shilimkar <santosh.shilimkar@ti.com>
On 02/04/2014 01:30 PM, Ivan Khoronzhuk wrote:
> Add broadcast clock-event device for the Keystone arch.
>
> The timer can be configured as a general-purpose 64-bit timer,
> dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or
> independently (unchained mode) of each other.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-keystone.c | 233 +++++++++++++++++++++++++++++++++++
> 2 files changed, 234 insertions(+)
> create mode 100644 drivers/clocksource/timer-keystone.c
>
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index c7ca50a..4abe5aa 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -37,3 +37,4 @@ obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
> obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
> obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
> obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
> +obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
> diff --git a/drivers/clocksource/timer-keystone.c b/drivers/clocksource/timer-keystone.c
> new file mode 100644
> index 0000000..cbac8d0
> --- /dev/null
> +++ b/drivers/clocksource/timer-keystone.c
> @@ -0,0 +1,233 @@
> +/*
> + * Keystone broadcast clock-event
> + *
> + * Copyright 2013 Texas Instruments, Inc.
> + *
> + * Author: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/clocksource.h>
> +#include <linux/interrupt.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +
> +#define TIMER_NAME "timer-keystone"
> +
> +/* Timer register offsets */
> +#define TIM12 0x10
> +#define TIM34 0x14
> +#define PRD12 0x18
> +#define PRD34 0x1c
> +#define TCR 0x20
> +#define TGCR 0x24
> +#define INTCTLSTAT 0x44
> +
> +/* Timer register bitfields */
> +#define TCR_ENAMODE_MASK 0xC0
> +#define TCR_ENAMODE_ONESHOT_MASK 0x40
> +#define TCR_ENAMODE_PERIODIC_MASK 0x80
> +
> +#define TGCR_TIM_UNRESET_MASK 0x03
> +#define INTCTLSTAT_ENINT_MASK 0x01
> +
> +/**
> + * struct keystone_timer: holds timer's data
> + * @base: timer memory base address
> + * @hz_period: cycles per HZ period
> + * @event_dev: event device based on timer
> + */
> +static struct keystone_timer {
> + void __iomem *base;
> + unsigned long hz_period;
> + struct clock_event_device event_dev;
> +} timer;
> +
> +static inline u32 keystone_timer_readl(unsigned long rg)
> +{
> + return readl_relaxed(timer.base + rg);
> +}
> +
> +static inline void keystone_timer_writel(u32 val, unsigned long rg)
> +{
> + writel_relaxed(val, timer.base + rg);
> +}
> +
> +/**
> + * keystone_timer_config: configures timer to work in oneshot/periodic modes.
> + * @ mode: mode to configure
> + * @ period: cycles number to configure for
> + */
> +static int keystone_timer_config(u64 period, enum clock_event_mode mode)
> +{
> + u32 tcr;
> + u32 off;
> +
> + tcr = keystone_timer_readl(TCR);
> + off = tcr & ~(TCR_ENAMODE_MASK);
> +
> + /* set enable mode */
> + switch (mode) {
> + case CLOCK_EVT_MODE_ONESHOT:
> + tcr |= TCR_ENAMODE_ONESHOT_MASK;
> + break;
> + case CLOCK_EVT_MODE_PERIODIC:
> + tcr |= TCR_ENAMODE_PERIODIC_MASK;
> + break;
> + default:
> + return -1;
> + }
> +
> + /* disable timer */
> + keystone_timer_writel(off, TCR);
> + /* here we have to be sure the timer has been disabled */
> + wmb();
> +
> + /* reset counter to zero, set new period */
> + keystone_timer_writel(0, TIM12);
> + keystone_timer_writel(0, TIM34);
> + keystone_timer_writel(period & 0xffffffff, PRD12);
> + keystone_timer_writel(period >> 32, PRD34);
> +
> + /*
> + * enable timer
> + * here we have to be sure that CNTLO, CNTHI, PRDLO, PRDHI registers
> + * have been written.
> + */
> + wmb();
> + keystone_timer_writel(tcr, TCR);
> + return 0;
> +}
> +
> +static void keystone_timer_disable(void)
> +{
> + u32 tcr;
> +
> + tcr = keystone_timer_readl(TCR);
> +
> + /* disable timer */
> + tcr &= ~(TCR_ENAMODE_MASK);
> + keystone_timer_writel(tcr, TCR);
> +}
> +
> +static irqreturn_t keystone_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> +
> + evt->event_handler(evt);
> + return IRQ_HANDLED;
> +}
> +
> +static int keystone_set_next_event(unsigned long cycles,
> + struct clock_event_device *evt)
> +{
> + return keystone_timer_config(cycles, evt->mode);
> +}
> +
> +static void keystone_set_mode(enum clock_event_mode mode,
> + struct clock_event_device *evt)
> +{
> + switch (mode) {
> + case CLOCK_EVT_MODE_PERIODIC:
> + keystone_timer_config(timer.hz_period, CLOCK_EVT_MODE_PERIODIC);
> + break;
> + case CLOCK_EVT_MODE_UNUSED:
> + case CLOCK_EVT_MODE_SHUTDOWN:
> + case CLOCK_EVT_MODE_ONESHOT:
> + keystone_timer_disable();
> + break;
> + default:
> + break;
> + }
> +}
> +
> +static void __init keystone_timer_init(struct device_node *np)
> +{
> + struct clock_event_device *event_dev = &timer.event_dev;
> + unsigned long rate;
> + struct clk *clk;
> + int irq, error;
> + u32 tgcr;
> +
> + irq = irq_of_parse_and_map(np, 0);
> + if (irq == NO_IRQ) {
> + pr_err("%s: failed to map interrupts\n", __func__);
> + return;
> + }
> +
> + timer.base = of_iomap(np, 0);
> + if (!timer.base) {
> + pr_err("%s: failed to map registers\n", __func__);
> + return;
> + }
> +
> + clk = of_clk_get(np, 0);
> + if (!clk) {
> + pr_err("%s: failed to get clock\n", __func__);
> + iounmap(timer.base);
> + return;
> + }
> +
> + error = clk_prepare_enable(clk);
> + if (error) {
> + pr_err("%s: failed to enable clock\n", __func__);
> + goto err;
> + }
> +
> + rate = clk_get_rate(clk);
> +
> + /* disable, use internal clock source */
> + keystone_timer_writel(0, TCR);
> + /* here we have to be sure the timer has been disabled */
> + wmb();
> +
> + /* reset timer as 64-bit, no pre-scaler, plus features are disabled */
> + tgcr = 0;
> + keystone_timer_writel(0, TGCR);
> +
> + /* unreset timer */
> + tgcr |= TGCR_TIM_UNRESET_MASK;
> + keystone_timer_writel(tgcr, TGCR);
> +
> + /* init counter to zero */
> + keystone_timer_writel(0, TIM12);
> + keystone_timer_writel(0, TIM34);
> +
> + timer.hz_period = DIV_ROUND_UP(rate, HZ);
> +
> + /* enable timer interrupts */
> + keystone_timer_writel(INTCTLSTAT_ENINT_MASK, INTCTLSTAT);
> +
> + error = request_irq(irq, keystone_timer_interrupt, IRQF_TIMER,
> + TIMER_NAME, event_dev);
> + if (error) {
> + pr_err("%s: failed to setup irq\n", __func__);
> + goto err;
> + }
> +
> + /* setup clockevent */
> + event_dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
> + event_dev->set_next_event = keystone_set_next_event;
> + event_dev->set_mode = keystone_set_mode;
> + event_dev->cpumask = cpu_all_mask;
> + event_dev->owner = THIS_MODULE;
> + event_dev->name = TIMER_NAME;
> + event_dev->irq = irq;
> +
> + clockevents_config_and_register(event_dev, rate, 1, ULONG_MAX);
> +
> + pr_info("keystone timer clock @%lu Hz\n", rate);
> + return;
> +err:
> + clk_put(clk);
> + iounmap(timer.base);
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(keystone_timer, "ti,keystone-timer",
> + keystone_timer_init);
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v4 3/3] arm: dts: keystone: add keystone timer entry
From: Ivan Khoronzhuk @ 2014-02-04 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391513453-21140-1-git-send-email-ivan.khoronzhuk@ti.com>
Add keystone timer entry to keystone device tree.
This 64-bit timer is used as backup clock event device.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
arch/arm/boot/dts/keystone-clocks.dtsi | 10 ++++++++++
arch/arm/boot/dts/keystone.dtsi | 7 +++++++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-clocks.dtsi b/arch/arm/boot/dts/keystone-clocks.dtsi
index 2363593..16d2aba 100644
--- a/arch/arm/boot/dts/keystone-clocks.dtsi
+++ b/arch/arm/boot/dts/keystone-clocks.dtsi
@@ -737,6 +737,16 @@ clocks {
domain-id = <0>;
};
+ clktimer15: clktimer15 {
+ #clock-cells = <0>;
+ compatible = "ti,keystone,psc-clock";
+ clocks = <&clkmodrst0>;
+ clock-output-names = "timer15";
+ reg = <0x02350000 0xb00>, <0x02350000 0x400>;
+ reg-names = "control", "domain";
+ domain-id = <0>;
+ };
+
clkuart0: clkuart0 {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index b420290..cac9841 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -208,5 +208,12 @@
usb-phy = <&usb_phy>, <&usb_phy>;
};
};
+
+ clock_event: timer at 22f0000 {
+ compatible = "ti,keystone-timer";
+ reg = <0x022f0000 0x80>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clktimer15>;
+ };
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-04 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391513453-21140-1-git-send-email-ivan.khoronzhuk@ti.com>
This patch provides bindings for the 64-bit timer in the KeyStone
architecture devices. The timer can be configured as a general-purpose 64-bit
timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
timers, each half can operate in conjunction (chain mode) or independently
(unchained mode) of each other.
It is global timer is a free running up-counter and can generate interrupt
when the counter reaches preset counter values.
Documentation:
http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
.../bindings/timer/ti,keystone-timer.txt | 29 ++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
new file mode 100644
index 0000000..5fbe361
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
@@ -0,0 +1,29 @@
+* Device tree bindings for Texas instruments Keystone timer
+
+This document provides bindings for the 64-bit timer in the KeyStone
+architecture devices. The timer can be configured as a general-purpose 64-bit
+timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
+timers, each half can operate in conjunction (chain mode) or independently
+(unchained mode) of each other.
+
+It is global timer is a free running up-counter and can generate interrupt
+when the counter reaches preset counter values.
+
+Documentation:
+http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
+
+Required properties:
+
+- compatible : should be "ti,keystone-timer".
+- reg : specifies base physical address and count of the registers.
+- interrupts : interrupt generated by the timer.
+- clocks : the clock feeding the timer clock.
+
+Example:
+
+timer at 22f0000 {
+ compatible = "ti,keystone-timer";
+ reg = <0x022f0000 0x80>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clktimer15>;
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 1/3] clocksource: timer-keystone: introduce clocksource driver for Keystone
From: Ivan Khoronzhuk @ 2014-02-04 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391513453-21140-1-git-send-email-ivan.khoronzhuk@ti.com>
Add broadcast clock-event device for the Keystone arch.
The timer can be configured as a general-purpose 64-bit timer,
dual general-purpose 32-bit timers. When configured as dual 32-bit
timers, each half can operate in conjunction (chain mode) or
independently (unchained mode) of each other.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
---
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-keystone.c | 233 +++++++++++++++++++++++++++++++++++
2 files changed, 234 insertions(+)
create mode 100644 drivers/clocksource/timer-keystone.c
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..4abe5aa 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
obj-$(CONFIG_ARCH_HAS_TICK_BROADCAST) += dummy_timer.o
+obj-$(CONFIG_ARCH_KEYSTONE) += timer-keystone.o
diff --git a/drivers/clocksource/timer-keystone.c b/drivers/clocksource/timer-keystone.c
new file mode 100644
index 0000000..cbac8d0
--- /dev/null
+++ b/drivers/clocksource/timer-keystone.c
@@ -0,0 +1,233 @@
+/*
+ * Keystone broadcast clock-event
+ *
+ * Copyright 2013 Texas Instruments, Inc.
+ *
+ * Author: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/interrupt.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#define TIMER_NAME "timer-keystone"
+
+/* Timer register offsets */
+#define TIM12 0x10
+#define TIM34 0x14
+#define PRD12 0x18
+#define PRD34 0x1c
+#define TCR 0x20
+#define TGCR 0x24
+#define INTCTLSTAT 0x44
+
+/* Timer register bitfields */
+#define TCR_ENAMODE_MASK 0xC0
+#define TCR_ENAMODE_ONESHOT_MASK 0x40
+#define TCR_ENAMODE_PERIODIC_MASK 0x80
+
+#define TGCR_TIM_UNRESET_MASK 0x03
+#define INTCTLSTAT_ENINT_MASK 0x01
+
+/**
+ * struct keystone_timer: holds timer's data
+ * @base: timer memory base address
+ * @hz_period: cycles per HZ period
+ * @event_dev: event device based on timer
+ */
+static struct keystone_timer {
+ void __iomem *base;
+ unsigned long hz_period;
+ struct clock_event_device event_dev;
+} timer;
+
+static inline u32 keystone_timer_readl(unsigned long rg)
+{
+ return readl_relaxed(timer.base + rg);
+}
+
+static inline void keystone_timer_writel(u32 val, unsigned long rg)
+{
+ writel_relaxed(val, timer.base + rg);
+}
+
+/**
+ * keystone_timer_config: configures timer to work in oneshot/periodic modes.
+ * @ mode: mode to configure
+ * @ period: cycles number to configure for
+ */
+static int keystone_timer_config(u64 period, enum clock_event_mode mode)
+{
+ u32 tcr;
+ u32 off;
+
+ tcr = keystone_timer_readl(TCR);
+ off = tcr & ~(TCR_ENAMODE_MASK);
+
+ /* set enable mode */
+ switch (mode) {
+ case CLOCK_EVT_MODE_ONESHOT:
+ tcr |= TCR_ENAMODE_ONESHOT_MASK;
+ break;
+ case CLOCK_EVT_MODE_PERIODIC:
+ tcr |= TCR_ENAMODE_PERIODIC_MASK;
+ break;
+ default:
+ return -1;
+ }
+
+ /* disable timer */
+ keystone_timer_writel(off, TCR);
+ /* here we have to be sure the timer has been disabled */
+ wmb();
+
+ /* reset counter to zero, set new period */
+ keystone_timer_writel(0, TIM12);
+ keystone_timer_writel(0, TIM34);
+ keystone_timer_writel(period & 0xffffffff, PRD12);
+ keystone_timer_writel(period >> 32, PRD34);
+
+ /*
+ * enable timer
+ * here we have to be sure that CNTLO, CNTHI, PRDLO, PRDHI registers
+ * have been written.
+ */
+ wmb();
+ keystone_timer_writel(tcr, TCR);
+ return 0;
+}
+
+static void keystone_timer_disable(void)
+{
+ u32 tcr;
+
+ tcr = keystone_timer_readl(TCR);
+
+ /* disable timer */
+ tcr &= ~(TCR_ENAMODE_MASK);
+ keystone_timer_writel(tcr, TCR);
+}
+
+static irqreturn_t keystone_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *evt = dev_id;
+
+ evt->event_handler(evt);
+ return IRQ_HANDLED;
+}
+
+static int keystone_set_next_event(unsigned long cycles,
+ struct clock_event_device *evt)
+{
+ return keystone_timer_config(cycles, evt->mode);
+}
+
+static void keystone_set_mode(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+ switch (mode) {
+ case CLOCK_EVT_MODE_PERIODIC:
+ keystone_timer_config(timer.hz_period, CLOCK_EVT_MODE_PERIODIC);
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
+ case CLOCK_EVT_MODE_SHUTDOWN:
+ case CLOCK_EVT_MODE_ONESHOT:
+ keystone_timer_disable();
+ break;
+ default:
+ break;
+ }
+}
+
+static void __init keystone_timer_init(struct device_node *np)
+{
+ struct clock_event_device *event_dev = &timer.event_dev;
+ unsigned long rate;
+ struct clk *clk;
+ int irq, error;
+ u32 tgcr;
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ pr_err("%s: failed to map interrupts\n", __func__);
+ return;
+ }
+
+ timer.base = of_iomap(np, 0);
+ if (!timer.base) {
+ pr_err("%s: failed to map registers\n", __func__);
+ return;
+ }
+
+ clk = of_clk_get(np, 0);
+ if (!clk) {
+ pr_err("%s: failed to get clock\n", __func__);
+ iounmap(timer.base);
+ return;
+ }
+
+ error = clk_prepare_enable(clk);
+ if (error) {
+ pr_err("%s: failed to enable clock\n", __func__);
+ goto err;
+ }
+
+ rate = clk_get_rate(clk);
+
+ /* disable, use internal clock source */
+ keystone_timer_writel(0, TCR);
+ /* here we have to be sure the timer has been disabled */
+ wmb();
+
+ /* reset timer as 64-bit, no pre-scaler, plus features are disabled */
+ tgcr = 0;
+ keystone_timer_writel(0, TGCR);
+
+ /* unreset timer */
+ tgcr |= TGCR_TIM_UNRESET_MASK;
+ keystone_timer_writel(tgcr, TGCR);
+
+ /* init counter to zero */
+ keystone_timer_writel(0, TIM12);
+ keystone_timer_writel(0, TIM34);
+
+ timer.hz_period = DIV_ROUND_UP(rate, HZ);
+
+ /* enable timer interrupts */
+ keystone_timer_writel(INTCTLSTAT_ENINT_MASK, INTCTLSTAT);
+
+ error = request_irq(irq, keystone_timer_interrupt, IRQF_TIMER,
+ TIMER_NAME, event_dev);
+ if (error) {
+ pr_err("%s: failed to setup irq\n", __func__);
+ goto err;
+ }
+
+ /* setup clockevent */
+ event_dev->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+ event_dev->set_next_event = keystone_set_next_event;
+ event_dev->set_mode = keystone_set_mode;
+ event_dev->cpumask = cpu_all_mask;
+ event_dev->owner = THIS_MODULE;
+ event_dev->name = TIMER_NAME;
+ event_dev->irq = irq;
+
+ clockevents_config_and_register(event_dev, rate, 1, ULONG_MAX);
+
+ pr_info("keystone timer clock @%lu Hz\n", rate);
+ return;
+err:
+ clk_put(clk);
+ iounmap(timer.base);
+}
+
+CLOCKSOURCE_OF_DECLARE(keystone_timer, "ti,keystone-timer",
+ keystone_timer_init);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 0/3] Introduce clocksource driver for Keystone platform
From: Ivan Khoronzhuk @ 2014-02-04 11:30 UTC (permalink / raw)
To: linux-arm-kernel
Add a broadcast timer64 based clockevent driver for keystone arch.
This driver uses timer in 64-bit general purpose mode as clock event
device.
Documentation:
http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master
v3..v4:
rebased on latest of linux-keystone.git keystone/master
v2..v3:
- clocksource: timer-keystone: introduce clocksource driver for
changed "u64" type to "unsigned long" for hz_period as more appropriate
hz_period rounded up by DIV_ROUND_UP(rate, HZ)
corrected comments
v1..v2:
- clocksource: timer-keystone: introduce clocksource driver for
renamed timer on "timer-keystone"
in keystone_timer_interrupt() evet pointer is passed via "dev_id"
used __relaxed variants of writel/readl and added explicit barriers
added "keystone_timer_disable()" for using in keystone_set_mode()
keystone_timer_config() is not used for disabling the timer any more
in case of an unsupported mode the keystone_timer_config() returns -1.
used request_irq() instead of setup_irq()
assigned irq for event_device in event_dev->irq
calculated timer.hz_period for CLOCK_EVT_MODE_PERIODIC at init
deleted spare call of keystone_timer_config() in keystone_timer_init()
*
Ivan Khoronzhuk (3):
clocksource: timer-keystone: introduce clocksource driver for Keystone
clocksource: keystone: add bindings for keystone timer
arm: dts: keystone: add keystone timer entry
.../bindings/timer/ti,keystone-timer.txt | 29 +++
arch/arm/boot/dts/keystone-clocks.dtsi | 10 +
arch/arm/boot/dts/keystone.dtsi | 7 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-keystone.c | 233 +++++++++++++++++++++
5 files changed, 280 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
create mode 100644 drivers/clocksource/timer-keystone.c
--
1.8.3.2
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Liviu Dudau @ 2014-02-04 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3277167.UhkSU8Sf56@wuerfel>
On Tue, Feb 04, 2014 at 08:44:36AM +0000, Arnd Bergmann wrote:
> On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 08:05:56PM +0000, Arnd Bergmann wrote:
> > > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > > > So ... defining it should mean no legacy ISA devices, right?
> > >
> > > I would read that comment as referring to systems that don't have
> > > any I/O space. If you have PCI, you can by definition have ISA
> > > compatible devices behind a bridge. A typical example would be
> > > a VGA card that supports the 03c0-03df port range.
> >
> > But if you have PCI and don't want to support ISA do you have /dev/port? I guess yes.
>
> Right, that is my interpretation. You could still have a tool
> that tries to poke /dev/port from user space for any I/O BAR
> the same way you'd use /dev/mem for memory BARs of PCI devices.
>
> It's discouraged, but it's often the easiest solution for
> a quick hack, and I'd expect tools to use this.
>
> > > > > > #define IO_SPACE_LIMIT 0xffff
> > > > >
> > > > > You probably want to increase this a bit, to allow multiple host bridges
> > > > > to have their own I/O space.
> > > >
> > > > OK, but to what size?
> > >
> > > 2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
> > > take up too much virtual space. On arm64 it should be at least as big.
> > > Could be more than that, although I don't see a reason why it should be,
> > > unless we expect to see systems with tons of host bridges, or buses
> > > that exceed 64KB of I/O space.
> >
> > I will increase the size to 2MB for v2.
>
> Thinking about this some more, I'd go a little higher. In case of
> pci_mv, we already register a 1MB region for one logical host
> (which has multiple I/O spaces behind an emulated bridge), so
> going to 16MB or more would let us handle multiple 1MB windows
> for some amount of future proofing.
>
> Maybe Catalin can assign us some virtual address space to use,
> with the constraints that it should be 16MB or more in an
> area that doesn't require additional kernel page table pages.
I'll pick Catalin's brain for suggestions.
>
> > > > > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > > > > > +#define ioport_unmap(addr)
> > > > >
> > > > > inline functions?
> > > >
> > > > Will do, thanks!
> > >
> > > I suppose you can actually use the generic implementation from
> > > asm-generic/io.h, and fix it by using the definition you have
> > > above, since it's currently broken.
> >
> > Not exactly broken, but it makes the assumption that your IO space starts at
> > physical address zero and you have not remapped it. It does guard the
> > definition with #ifndef CONFIG_GENERIC_IOMAP after all, so it does not
> > expect to be generic :)
>
> Well, I/O space never starts at physical zero in reality, so it is
> broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
> the problem of I/O spaces that are not memory mapped, which is
> actually quite rare (x86, ia64, some rare powerpc bridges, and possibly
> Alpha). The norm is that if you have I/O space, it is memory mapped
> and you don't need GENERIC_IOMAP. I think most of the architectures
> selecting GENERIC_IOMAP have incorrectly copied that from x86.
If you are talking about CPU addresses for I/O space, then you are (mostly?) right.
I've seen some code in powerpc that tries to handle the case where I/O starts at zero.
For MMIO, yes, it would be crazy to start at CPU address zero. But, the ioport_map
takes a port number, and those do start at zero, right?
>
> > > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > > > > > new file mode 100644
> > > > > > index 0000000..dd084a3
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/include/asm/pci.h
> > > > > > @@ -0,0 +1,35 @@
> > > > > > +#ifndef __ASM_PCI_H
> > > > > > +#define __ASM_PCI_H
> > > > > > +#ifdef __KERNEL__
> > > > > > +
> > > > > > +#include <linux/types.h>
> > > > > > +#include <linux/slab.h>
> > > > > > +#include <linux/dma-mapping.h>
> > > > > > +
> > > > > > +#include <asm/io.h>
> > > > > > +#include <asm-generic/pci-bridge.h>
> > > > > > +#include <asm-generic/pci-dma-compat.h>
> > > > > > +
> > > > > > +#define PCIBIOS_MIN_IO 0
> > > > > > +#define PCIBIOS_MIN_MEM 0
> > > > >
> > > > > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> > > >
> > > > :) No ISA support! (Die ISA, die!!)
> > >
> > > If only it were that easy.
> >
> > Lets try! :)
> >
> > I wonder how many active devices that have an ISA slot are still supported
> > by mainline kernel.
>
> This is missing the point, but any architecture that has a PCI
> slot can have an ISA device behind a bridge like this:
>
> http://www.altera.com/products/ip/iup/pci/m-eur-pci-to-isa.html
>
> The real reason is that a lot of PCI cards for practical reasons
> expose some non-relocatable memory and I/O BARs in ISA-compatible
> locations. Looking at /proc/ioports on my PC, I can spot a couple
> of things that may well show up on any ARM machine:
>
> 0000-03af : PCI Bus 0000:00
> 02f8-02ff : serial
> 03c0-03df : PCI Bus 0000:40
> 03c0-03df : PCI Bus 0000:00
> 03c0-03df : vga+
> 03e0-0cf7 : PCI Bus 0000:00
> 03e8-03ef : serial
> 03f8-03ff : serial
> 0b00-0b0f : pnp 00:08
> 0b00-0b07 : piix4_smbus
> 0b20-0b3f : pnp 00:08
> 0b20-0b27 : piix4_smbus
> 0ca2-0ca3 : pnp 00:08
> 0ca2-0ca2 : ipmi_si
> 0ca3-0ca3 : ipmi_si
> 0cf8-0cff : PCI conf1
>
> Nothing wrong with the above. Now, it's also possible that
> someone decides to build an ARM server by using a PC south
> bridge with integrated legacy PC peripherals, such as these:
>
> 0000-03af : PCI Bus 0000:00
> 0000-001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-0060 : keyboard
> 0064-0064 : keyboard
> 0070-0071 : rtc0
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00b0-00b0 : APEI ERST
> 00c0-00df : dma2
> 00f0-00ff : fpu
>
> There is some hope that it won't happen, but these things
> exist and come with a regular PCIe front-end bus in some
> cases.
>
> Finally, there is the LPC bus, which can give you additional
> ISAPnP compatible devices.
>
> > I will update PCIBIOS_MIN_xxxx to match arch/arm for v2.
>
> Ok.
>
> > > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > > > > new file mode 100644
> > > > > > index 0000000..7b652cf
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/kernel/pci.c
> > > > > > @@ -0,0 +1,112 @@
> > > > >
> > > > > None of this looks really arm64 specific, nor should it be. I think
> > > > > we should try a little harder to move this as a default implementation
> > > > > into common code, even if we start out by having all architectures
> > > > > override it.
> > > >
> > > > Agree. This is the RFC version. I didn't dare to post a patch with fixes
> > > > for all architectures. :)
> > >
> > > No need to change the other architectures. You can make it opt-in for
> > > now and just put the code into a common location.
> > >
> > > An interesting question however is what the transition plan is to
> > > have the code shared between arm32 and arm64: We will certainly need
> > > to share at least the dw-pcie and the generic SBSA compliant pci
> > > implementation.
> >
> > My vote would be for updating the host controllers to the new API and
> > to offer the CONFIG option to choose between arch APIs. The alternative
> > is to use the existing API to wrap the generic implementation.
>
> The problem with an either/or CONFIG option is that it breaks
> multiplatform support. A lot of the arm32 PCI implementations
> are only used on platforms that are not multiplatform enabled
> though, so we could get away by requiring all multiplatform
> configurations to use the new API.
I was thinking more in terms of catching uses of the old API in the new host bridge
driver. The added functions should be able to live beside the old API for the
generic PCI framework, not sure how arm arch code should handle it.
>
> > My main concern with the existing API is the requirement to have a subsys_initcall
> > in your host bridge or mach code, due to the way the initialisation is done (you
> > need the DT code to probe your driver, but you cannot start the scanning of the
> > PCI bus until the arch code is initialised, so it gets deferred via
> > subsys_initcall when it calls pci_common_init). I bet that if one tries to
> > instantiate a Tegra PCI host bridge controller on a Marvell platform things will
> > break pretty quickly (random example here).
>
> I'm not following here. All the new host controller drivers should
> be platform drivers that only bind to the host devices in DT
> that are present. Both mvebu and tegra use a normal "module_platform_driver"
> for initialization, not a "subsys_initcall".
I was actually looking at mach-dove, I thought that was Marvell as well.
But both mvebu and tegra call pci_common_init_dev. The busnr gets assigned based on
the registration order. I wonder if any of the host bridge code copes with having
assigned a bus number other than zero for its "root bus".
>
> > > Something like this (coded in mail client, don't try to compile):
> > >
> > > #define IO_SPACE_PAGES (IO_SPACE_LIMIT + 1) / PAGE_SIZE)
> > > static DECLARE_BITMAP(pci_iospace, IO_SPACE_PAGES);
> > > unsigned long pci_ioremap_io(const struct resource *bus, const struct resource phys)
> > > {
> > > unsigned long start, len, virt_start;
> > > int error;
> > >
> > > /* use logical address == bus address if possible */
> > > start = bus->start / PAGE_SIZE;
> > > if (start > IO_SPACE_LIMIT / PAGE_SIZE)
> > > start = 0;
> > >
> > > /*
> > > * try finding free space for the whole size first,
> > > * fall back to 64K if not available
> > > */
> > > len = min(resource_size(bus), resource_size(phys);
> > > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > > start, len / PAGE_SIZE, 0);
> > > if (start == IO_SPACE_PAGES && len > SZ_64K)
> > > len = SZ_64K;
> > > start = 0;
> > > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > > start, len / PAGE_SIZE, 0);
> > > }
> > >
> > > /* no 64K area found */
> > > if (start == IO_SPACE_PAGES)
> > > return -ENOMEM;
> > >
> > > /* ioremap physical aperture to virtual aperture */
> > > virt_start = start * PAGE_SIZE + (unsigned long)PCI_IOBASE;
> > > error = ioremap_page_range(virt_start, virt_start + len,
> > > phys->start, __pgprot(PROT_DEVICE_nGnRE));
> > > if (error)
> > > return error;
> > >
> > > bitmap_set(start, len / PAGE_SIZE);
> > >
> > > /* return io_offset */
> > > return start * PAGE_SIZE - bus->start;
> > > }
> > > EXPORT_SYMBOL_GPL(pci_ioremap_io);
> > >
> > > Arnd
> > >
> >
> > I see. I need to think how this will change the existing code. Current users
> > of pci_ioremap_io ask for multiples of SZ_64K offsets regardless of the
> > actual need.
>
> Right. I guess we can support both interfaces on ARM32 for the forseeable
> future (renaming the new one) and just change the existing implementation
> to update the bitmap. Any cross-platform host controller driver would
> have to use the new interface however.
>
> Arnd
OK, I can try to add the function to my patch. Call it pci_ioremap_iores?
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Mark Brown @ 2014-02-04 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391493268-3242-1-git-send-email-bjorn.andersson@sonymobile.com>
On Mon, Feb 03, 2014 at 09:54:28PM -0800, Bjorn Andersson wrote:
> + /*
> + * Make the regulator reflect the configured voltage selected in
> + * machine_constraints_voltage()
> + */
> + if (rdev->constraints->apply_uV &&
> + rdev->constraints->min_uV == rdev->constraints->max_uV) {
> + regulator->min_uV = rdev->constraints->min_uV;
> + regulator->max_uV = rdev->constraints->min_uV;
> + }
> +
Why not do this at the time we apply the voltage? That would seem to be
more robust, doing it in a separate place means that we might update one
bit of code and not the other or might change the execution path so that
one gets run and the other doesn't.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/539dcbfa/attachment.sig>
^ 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