* [PATCH V5 4/8] mfd: da9061: MFD core support
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: LINUX-KERNEL, Lee Jones
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck,
Zhang Rui
In-Reply-To: <cover.1481828921.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
MFD support for DA9061 is provided as part of the DA9062 device driver.
The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.
The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.
A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.
The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.9
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
- Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
them with DEFINE_RES_IRQ_NAMED().
- Removed whitespace
- Reverted change for badly defined mfd_cell da9062_devs of_compatible
string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
v1 -> v2
- Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Fixed typo in the commit message "readble" to "readable"
- Removed the explicit cross-check to decide if there is a conflict
between the device tree compatible string and the hardware definition.
This patch assumes the device tree is correctly written and therefore
removes the need for a hardware/DT sanity check.
- Removed extra semicolon in drivers/mfd/da9062-core.c:877
- Re-write compatible entries into numerical order
Lee,
Changes as described in the version history above.
As previously:
This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 424 +++++++++++++++++++++++++++++++++--
include/linux/mfd/da9062/core.h | 27 ++-
include/linux/mfd/da9062/registers.h | 2 +
4 files changed, 439 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c6df644..a1a780c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -246,13 +246,14 @@ config MFD_DA9055
called "da9055"
config MFD_DA9062
- tristate "Dialog Semiconductor DA9062 PMIC Support"
+ tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
This includes the I2C driver and core APIs.
Additional drivers must be enabled in order to use the functionality
of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..4b5f70f 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,5 +1,5 @@
/*
- * Core, IRQ and I2C device driver for DA9062 PMIC
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -30,6 +30,70 @@
#define DA9062_REG_EVENT_B_OFFSET 1
#define DA9062_REG_EVENT_C_OFFSET 2
+static struct regmap_irq da9061_irqs[] = {
+ /* EVENT A */
+ [DA9061_IRQ_ONKEY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_NONKEY_MASK,
+ },
+ [DA9061_IRQ_WDG_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_WDG_WARN_MASK,
+ },
+ [DA9061_IRQ_SEQ_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_SEQ_RDY_MASK,
+ },
+ /* EVENT B */
+ [DA9061_IRQ_TEMP] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_TEMP_MASK,
+ },
+ [DA9061_IRQ_LDO_LIM] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_LDO_LIM_MASK,
+ },
+ [DA9061_IRQ_DVC_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_DVC_RDY_MASK,
+ },
+ [DA9061_IRQ_VDD_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_VDD_WARN_MASK,
+ },
+ /* EVENT C */
+ [DA9061_IRQ_GPI0] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI0_MASK,
+ },
+ [DA9061_IRQ_GPI1] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI1_MASK,
+ },
+ [DA9061_IRQ_GPI2] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI2_MASK,
+ },
+ [DA9061_IRQ_GPI3] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI3_MASK,
+ },
+ [DA9061_IRQ_GPI4] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI4_MASK,
+ },
+};
+
+static struct regmap_irq_chip da9061_irq_chip = {
+ .name = "da9061-irq",
+ .irqs = da9061_irqs,
+ .num_irqs = DA9061_NUM_IRQ,
+ .num_regs = 3,
+ .status_base = DA9062AA_EVENT_A,
+ .mask_base = DA9062AA_IRQ_MASK_A,
+ .ack_base = DA9062AA_EVENT_A,
+};
+
static struct regmap_irq da9062_irqs[] = {
/* EVENT A */
[DA9062_IRQ_ONKEY] = {
@@ -102,6 +166,57 @@
.ack_base = DA9062AA_EVENT_A,
};
+static struct resource da9061_core_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_VDD_WARN, "VDD_WARN"),
+};
+
+static struct resource da9061_regulators_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_LDO_LIM, "LDO_LIM"),
+};
+
+static struct resource da9061_thermal_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_TEMP, "THERMAL"),
+};
+
+static struct resource da9061_wdt_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_WDG_WARN, "WD_WARN"),
+};
+
+static struct resource da9061_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_ONKEY, "ONKEY"),
+};
+
+static const struct mfd_cell da9061_devs[] = {
+ {
+ .name = "da9061-core",
+ .num_resources = ARRAY_SIZE(da9061_core_resources),
+ .resources = da9061_core_resources,
+ },
+ {
+ .name = "da9062-regulators",
+ .num_resources = ARRAY_SIZE(da9061_regulators_resources),
+ .resources = da9061_regulators_resources,
+ },
+ {
+ .name = "da9061-watchdog",
+ .num_resources = ARRAY_SIZE(da9061_wdt_resources),
+ .resources = da9061_wdt_resources,
+ .of_compatible = "dlg,da9061-watchdog",
+ },
+ {
+ .name = "da9061-thermal",
+ .num_resources = ARRAY_SIZE(da9061_thermal_resources),
+ .resources = da9061_thermal_resources,
+ .of_compatible = "dlg,da9061-thermal",
+ },
+ {
+ .name = "da9061-onkey",
+ .num_resources = ARRAY_SIZE(da9061_onkey_resources),
+ .resources = da9061_onkey_resources,
+ .of_compatible = "dlg,da9061-onkey",
+ },
+};
+
static struct resource da9062_core_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
};
@@ -200,7 +315,8 @@ static int da9062_clear_fault_log(struct da9062 *chip)
static int da9062_get_device_type(struct da9062 *chip)
{
- int device_id, variant_id, variant_mrc;
+ int device_id, variant_id, variant_mrc, variant_vrc;
+ char *type;
int ret;
ret = regmap_read(chip->regmap, DA9062AA_DEVICE_ID, &device_id);
@@ -219,9 +335,23 @@ static int da9062_get_device_type(struct da9062 *chip)
return -EIO;
}
+ variant_vrc = (variant_id & DA9062AA_VRC_MASK) >> DA9062AA_VRC_SHIFT;
+
+ switch (variant_vrc) {
+ case DA9062_PMIC_VARIANT_VRC_DA9061:
+ type = "DA9061";
+ break;
+ case DA9062_PMIC_VARIANT_VRC_DA9062:
+ type = "DA9062";
+ break;
+ default:
+ type = "Unknown";
+ break;
+ }
+
dev_info(chip->dev,
- "Device detected (device-ID: 0x%02X, var-ID: 0x%02X)\n",
- device_id, variant_id);
+ "Device detected (device-ID: 0x%02X, var-ID: 0x%02X, %s)\n",
+ device_id, variant_id, type);
variant_mrc = (variant_id & DA9062AA_MRC_MASK) >> DA9062AA_MRC_SHIFT;
@@ -234,6 +364,234 @@ static int da9062_get_device_type(struct da9062 *chip)
return ret;
}
+static const struct regmap_range da9061_aa_readable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_INTERFACE,
+ .range_max = DA9062AA_CONFIG_E,
+ }, {
+ .range_min = DA9062AA_CONFIG_G,
+ .range_max = DA9062AA_CONFIG_K,
+ }, {
+ .range_min = DA9062AA_CONFIG_M,
+ .range_max = DA9062AA_CONFIG_M,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ }, {
+ .range_min = DA9062AA_DEVICE_ID,
+ .range_max = DA9062AA_CONFIG_ID,
+ },
+};
+
+static const struct regmap_range da9061_aa_writeable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_PAGE_CON,
+ }, {
+ .range_min = DA9062AA_FAULT_LOG,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ },
+};
+
+static const struct regmap_range da9061_aa_volatile_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_CONTROL_B,
+ }, {
+ .range_min = DA9062AA_CONTROL_E,
+ .range_max = DA9062AA_CONTROL_F,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_SEQ,
+ },
+};
+
+static const struct regmap_access_table da9061_aa_readable_table = {
+ .yes_ranges = da9061_aa_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_readable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_writeable_table = {
+ .yes_ranges = da9061_aa_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_writeable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_volatile_table = {
+ .yes_ranges = da9061_aa_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_volatile_ranges),
+};
+
+static const struct regmap_range_cfg da9061_range_cfg[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_CONFIG_ID,
+ .selector_reg = DA9062AA_PAGE_CON,
+ .selector_mask = 1 << DA9062_I2C_PAGE_SEL_SHIFT,
+ .selector_shift = DA9062_I2C_PAGE_SEL_SHIFT,
+ .window_start = 0,
+ .window_len = 256,
+ }
+};
+
+static struct regmap_config da9061_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .ranges = da9061_range_cfg,
+ .num_ranges = ARRAY_SIZE(da9061_range_cfg),
+ .max_register = DA9062AA_CONFIG_ID,
+ .cache_type = REGCACHE_RBTREE,
+ .rd_table = &da9061_aa_readable_table,
+ .wr_table = &da9061_aa_writeable_table,
+ .volatile_table = &da9061_aa_volatile_table,
+};
+
static const struct regmap_range da9062_aa_readable_ranges[] = {
{
.range_min = DA9062AA_PAGE_CON,
@@ -456,17 +814,38 @@ static int da9062_get_device_type(struct da9062 *chip)
.volatile_table = &da9062_aa_volatile_table,
};
+static const struct of_device_id da9062_dt_ids[] = {
+ { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061, },
+ { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da9062_dt_ids);
+
static int da9062_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct da9062 *chip;
+ const struct of_device_id *match;
unsigned int irq_base;
+ const struct mfd_cell *cell;
+ const struct regmap_irq_chip *irq_chip;
+ const struct regmap_config *config;
+ int cell_num;
int ret;
chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
+ if (i2c->dev.of_node) {
+ match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
+ if (!match)
+ return -EINVAL;
+
+ chip->chip_type = (int)match->data;
+ } else
+ chip->chip_type = id->driver_data;
+
i2c_set_clientdata(i2c, chip);
chip->dev = &i2c->dev;
@@ -475,7 +854,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
return -EINVAL;
}
- chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+ switch (chip->chip_type) {
+ case(COMPAT_TYPE_DA9061):
+ cell = da9061_devs;
+ cell_num = ARRAY_SIZE(da9061_devs);
+ irq_chip = &da9061_irq_chip;
+ config = &da9061_regmap_config;
+ break;
+ case(COMPAT_TYPE_DA9062):
+ cell = da9062_devs;
+ cell_num = ARRAY_SIZE(da9062_devs);
+ irq_chip = &da9062_irq_chip;
+ config = &da9062_regmap_config;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
+
+ chip->regmap = devm_regmap_init_i2c(i2c, config);
if (IS_ERR(chip->regmap)) {
ret = PTR_ERR(chip->regmap);
dev_err(chip->dev, "Failed to allocate register map: %d\n",
@@ -493,7 +890,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
- -1, &da9062_irq_chip,
+ -1, irq_chip,
&chip->regmap_irq);
if (ret) {
dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
@@ -503,8 +900,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
- ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
- ARRAY_SIZE(da9062_devs), NULL, irq_base,
+ ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
+ cell_num, NULL, irq_base,
NULL);
if (ret) {
dev_err(chip->dev, "Cannot register child devices\n");
@@ -526,17 +923,12 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id da9062_i2c_id[] = {
- { "da9062", 0 },
+ { "da9061", COMPAT_TYPE_DA9061 },
+ { "da9062", COMPAT_TYPE_DA9062 },
{ },
};
MODULE_DEVICE_TABLE(i2c, da9062_i2c_id);
-static const struct of_device_id da9062_dt_ids[] = {
- { .compatible = "dlg,da9062", },
- { }
-};
-MODULE_DEVICE_TABLE(of, da9062_dt_ids);
-
static struct i2c_driver da9062_i2c_driver = {
.driver = {
.name = "da9062",
@@ -549,6 +941,6 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
module_i2c_driver(da9062_i2c_driver);
-MODULE_DESCRIPTION("Core device driver for Dialog DA9062");
+MODULE_DESCRIPTION("Core device driver for Dialog DA9061 and DA9062");
MODULE_AUTHOR("Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>");
MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/da9062/core.h b/include/linux/mfd/da9062/core.h
index 376ba84..199c524 100644
--- a/include/linux/mfd/da9062/core.h
+++ b/include/linux/mfd/da9062/core.h
@@ -18,7 +18,31 @@
#include <linux/interrupt.h>
#include <linux/mfd/da9062/registers.h>
-/* Interrupts */
+enum da9062_compatible_types {
+ COMPAT_TYPE_DA9061 = 1,
+ COMPAT_TYPE_DA9062,
+};
+
+enum da9061_irqs {
+ /* IRQ A */
+ DA9061_IRQ_ONKEY,
+ DA9061_IRQ_WDG_WARN,
+ DA9061_IRQ_SEQ_RDY,
+ /* IRQ B*/
+ DA9061_IRQ_TEMP,
+ DA9061_IRQ_LDO_LIM,
+ DA9061_IRQ_DVC_RDY,
+ DA9061_IRQ_VDD_WARN,
+ /* IRQ C */
+ DA9061_IRQ_GPI0,
+ DA9061_IRQ_GPI1,
+ DA9061_IRQ_GPI2,
+ DA9061_IRQ_GPI3,
+ DA9061_IRQ_GPI4,
+
+ DA9061_NUM_IRQ,
+};
+
enum da9062_irqs {
/* IRQ A */
DA9062_IRQ_ONKEY,
@@ -45,6 +69,7 @@ struct da9062 {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irq;
+ enum da9062_compatible_types chip_type;
};
#endif /* __MFD_DA9062_CORE_H__ */
diff --git a/include/linux/mfd/da9062/registers.h b/include/linux/mfd/da9062/registers.h
index 97790d1..4457fdc 100644
--- a/include/linux/mfd/da9062/registers.h
+++ b/include/linux/mfd/da9062/registers.h
@@ -18,6 +18,8 @@
#define DA9062_PMIC_DEVICE_ID 0x62
#define DA9062_PMIC_VARIANT_MRC_AA 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9061 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9062 0x02
#define DA9062_I2C_PAGE_SEL_SHIFT 1
--
end-of-patch for PATCH V5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V5 5/8] regulator: da9061: BUCK and LDO regulator driver
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: LINUX-KERNEL, Liam Girdwood, Mark Brown
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Lee Jones, Mark Rutland,
Rob Herring, Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <cover.1481828921.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Regulator support for the DA9061 is added into the DA9062 regulator driver.
The regulators for DA9061 differ from those of DA9062.
A new DA9061 enumeration list for the LDOs and Bucks supported by this
device is added. Regulator information added: the old regulator
information for DA9062 is renamed from local_regulator_info[] to
local_da9062_regulator_info[] and a new array is added to support
local_da9061_regulator_info[].
The probe() function switches on the da9062_compatible_types enumeration
and configures the correct da9062_regulator_info array and number of
regulator entries.
Kconfig is updated to reflect support for DA9061 and DA9062 regulators.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.9
v4 -> v5
- Rebased from v4.8 to v4.9
- NO CODE CHANGE
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 6/9] to [PATCH V4 5/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 06/10] to [PATCH V3 6/9]
- Added Ack from Mark Brown
v1 -> v2
- Patch renamed from [PATCH V1 02/10] to [PATCH V2 06/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Updated header to use DA9061 and DA9062
Hi,
No code changes for this version PATCH V5.
As previously:
These changes depend on a header file provided as part of an earlier
patch [PATCH V5 4/8] from this set. The regulator probe() switches on
the chip_type which uses enum da9062_compatible_types in core.h from this
patch.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 301 +++++++++++++++++++++++++++++++++--
2 files changed, 292 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 936f7cc..bbb4be6 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -188,11 +188,11 @@ config REGULATOR_DA9055
will be called da9055-regulator.
config REGULATOR_DA9062
- tristate "Dialog Semiconductor DA9062 regulators"
+ tristate "Dialog Semiconductor DA9061/62 regulators"
depends on MFD_DA9062
help
Say y here to support the BUCKs and LDOs regulators found on
- DA9062 PMICs.
+ DA9061 and DA9062 PMICs.
This driver can also be built as a module. If so, the module
will be called da9062-regulator.
diff --git a/drivers/regulator/da9062-regulator.c b/drivers/regulator/da9062-regulator.c
index 0638c8b..931be68 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -1,5 +1,5 @@
/*
- * da9062-regulator.c - REGULATOR device driver for DA9062
+ * Regulator device driver for DA9061 and DA9062.
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -28,6 +28,17 @@
/* Regulator IDs */
enum {
+ DA9061_ID_BUCK1,
+ DA9061_ID_BUCK2,
+ DA9061_ID_BUCK3,
+ DA9061_ID_LDO1,
+ DA9061_ID_LDO2,
+ DA9061_ID_LDO3,
+ DA9061_ID_LDO4,
+ DA9061_MAX_REGULATORS,
+};
+
+enum {
DA9062_ID_BUCK1,
DA9062_ID_BUCK2,
DA9062_ID_BUCK3,
@@ -88,15 +99,21 @@ enum {
/* Regulator operations */
-/* Current limits array (in uA) BUCK1 and BUCK3.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_[BUCK1|BUCK3]
+ * - DA9062_ID_[BUCK1|BUCK2|BUCK4]
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_a_limits[] = {
500000, 600000, 700000, 800000, 900000, 1000000, 1100000, 1200000,
1300000, 1400000, 1500000, 1600000, 1700000, 1800000, 1900000, 2000000
};
-/* Current limits array (in uA) for BUCK2.
- Entry indexes corresponds to register values. */
+/* Current limits array (in uA)
+ * - DA9061_ID_BUCK2
+ * - DA9062_ID_BUCK3
+ * Entry indexes corresponds to register values.
+ */
static const int da9062_buck_b_limits[] = {
1500000, 1600000, 1700000, 1800000, 1900000, 2000000, 2100000, 2200000,
2300000, 2400000, 2500000, 2600000, 2700000, 2800000, 2900000, 3000000
@@ -405,8 +422,254 @@ static int da9062_ldo_set_suspend_mode(struct regulator_dev *rdev,
.set_suspend_mode = da9062_ldo_set_suspend_mode,
};
-/* Regulator information */
-static const struct da9062_regulator_info local_regulator_info[] = {
+/* DA9061 Regulator information */
+static const struct da9062_regulator_info local_da9061_regulator_info[] = {
+ {
+ .desc.id = DA9061_ID_BUCK1,
+ .desc.name = "DA9061 BUCK1",
+ .desc.of_match = of_match_ptr("buck1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (300) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1570) - (300))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK1_CONT,
+ .desc.enable_mask = DA9062AA_BUCK1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK1_A,
+ .desc.vsel_mask = DA9062AA_VBUCK1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK1_A,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK1_B,
+ __builtin_ffs((int)DA9062AA_BUCK1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK1_B,
+ .mode = REG_FIELD(DA9062AA_BUCK1_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK1_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK1_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_C,
+ __builtin_ffs((int)DA9062AA_BUCK1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK2,
+ .desc.name = "DA9061 BUCK2",
+ .desc.of_match = of_match_ptr("buck2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (800) * 1000,
+ .desc.uV_step = (20) * 1000,
+ .desc.n_voltages = ((3340) - (800))/(20) + 1,
+ .current_limits = da9062_buck_b_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_b_limits),
+ .desc.enable_reg = DA9062AA_BUCK3_CONT,
+ .desc.enable_mask = DA9062AA_BUCK3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK3_A,
+ .desc.vsel_mask = DA9062AA_VBUCK3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK3_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK3_B,
+ __builtin_ffs((int)DA9062AA_BUCK3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK3_B,
+ .mode = REG_FIELD(DA9062AA_BUCK3_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK3_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK3_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_A,
+ __builtin_ffs((int)DA9062AA_BUCK3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_BUCK3,
+ .desc.name = "DA9061 BUCK3",
+ .desc.of_match = of_match_ptr("buck3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_buck_ops,
+ .desc.min_uV = (530) * 1000,
+ .desc.uV_step = (10) * 1000,
+ .desc.n_voltages = ((1800) - (530))/(10) + 1,
+ .current_limits = da9062_buck_a_limits,
+ .n_current_limits = ARRAY_SIZE(da9062_buck_a_limits),
+ .desc.enable_reg = DA9062AA_BUCK4_CONT,
+ .desc.enable_mask = DA9062AA_BUCK4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VBUCK4_A,
+ .desc.vsel_mask = DA9062AA_VBUCK4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VBUCK4_A,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VBUCK4_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VBUCK4_B,
+ .mode = REG_FIELD(DA9062AA_BUCK4_CFG,
+ __builtin_ffs((int)DA9062AA_BUCK4_MODE_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_MODE_MASK)) - 1),
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VBUCK4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VBUCK4_SEL_MASK)) - 1),
+ .ilimit = REG_FIELD(DA9062AA_BUCK_ILIM_B,
+ __builtin_ffs((int)DA9062AA_BUCK4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_BUCK4_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO1,
+ .desc.name = "DA9061 LDO1",
+ .desc.of_match = of_match_ptr("ldo1"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO1_CONT,
+ .desc.enable_mask = DA9062AA_LDO1_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO1_A,
+ .desc.vsel_mask = DA9062AA_VLDO1_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO1_A,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO1_B,
+ __builtin_ffs((int)DA9062AA_LDO1_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO1_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO1_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO1_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO1_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO1_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO2,
+ .desc.name = "DA9061 LDO2",
+ .desc.of_match = of_match_ptr("ldo2"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (600))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO2_CONT,
+ .desc.enable_mask = DA9062AA_LDO2_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO2_A,
+ .desc.vsel_mask = DA9062AA_VLDO2_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO2_A,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO2_B,
+ __builtin_ffs((int)DA9062AA_LDO2_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO2_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO2_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO2_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO2_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO2_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO3,
+ .desc.name = "DA9061 LDO3",
+ .desc.of_match = of_match_ptr("ldo3"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO3_CONT,
+ .desc.enable_mask = DA9062AA_LDO3_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO3_A,
+ .desc.vsel_mask = DA9062AA_VLDO3_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO3_A,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO3_B,
+ __builtin_ffs((int)DA9062AA_LDO3_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO3_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO3_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO3_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO3_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO3_ILIM_MASK)) - 1),
+ },
+ {
+ .desc.id = DA9061_ID_LDO4,
+ .desc.name = "DA9061 LDO4",
+ .desc.of_match = of_match_ptr("ldo4"),
+ .desc.regulators_node = of_match_ptr("regulators"),
+ .desc.ops = &da9062_ldo_ops,
+ .desc.min_uV = (900) * 1000,
+ .desc.uV_step = (50) * 1000,
+ .desc.n_voltages = ((3600) - (900))/(50) + 1,
+ .desc.enable_reg = DA9062AA_LDO4_CONT,
+ .desc.enable_mask = DA9062AA_LDO4_EN_MASK,
+ .desc.vsel_reg = DA9062AA_VLDO4_A,
+ .desc.vsel_mask = DA9062AA_VLDO4_A_MASK,
+ .desc.linear_min_sel = 0,
+ .sleep = REG_FIELD(DA9062AA_VLDO4_A,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_A_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_A_MASK)) - 1),
+ .suspend_sleep = REG_FIELD(DA9062AA_VLDO4_B,
+ __builtin_ffs((int)DA9062AA_LDO4_SL_B_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_SL_B_MASK)) - 1),
+ .suspend_vsel_reg = DA9062AA_VLDO4_B,
+ .suspend = REG_FIELD(DA9062AA_DVC_1,
+ __builtin_ffs((int)DA9062AA_VLDO4_SEL_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_VLDO4_SEL_MASK)) - 1),
+ .oc_event = REG_FIELD(DA9062AA_STATUS_D,
+ __builtin_ffs((int)DA9062AA_LDO4_ILIM_MASK) - 1,
+ sizeof(unsigned int) * 8 -
+ __builtin_clz((DA9062AA_LDO4_ILIM_MASK)) - 1),
+ },
+};
+
+/* DA9062 Regulator information */
+static const struct da9062_regulator_info local_da9062_regulator_info[] = {
{
.desc.id = DA9062_ID_BUCK1,
.desc.name = "DA9062 BUCK1",
@@ -727,17 +990,33 @@ static int da9062_regulator_probe(struct platform_device *pdev)
struct da9062_regulators *regulators;
struct da9062_regulator *regl;
struct regulator_config config = { };
+ const struct da9062_regulator_info *rinfo;
int irq, n, ret;
size_t size;
+ int max_regulators;
+
+ switch (chip->chip_type) {
+ case COMPAT_TYPE_DA9061:
+ max_regulators = DA9061_MAX_REGULATORS;
+ rinfo = local_da9061_regulator_info;
+ break;
+ case COMPAT_TYPE_DA9062:
+ max_regulators = DA9062_MAX_REGULATORS;
+ rinfo = local_da9062_regulator_info;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
/* Allocate memory required by usable regulators */
size = sizeof(struct da9062_regulators) +
- DA9062_MAX_REGULATORS * sizeof(struct da9062_regulator);
+ max_regulators * sizeof(struct da9062_regulator);
regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
if (!regulators)
return -ENOMEM;
- regulators->n_regulators = DA9062_MAX_REGULATORS;
+ regulators->n_regulators = max_regulators;
platform_set_drvdata(pdev, regulators);
n = 0;
@@ -745,7 +1024,7 @@ static int da9062_regulator_probe(struct platform_device *pdev)
/* Initialise regulator structure */
regl = ®ulators->regulator[n];
regl->hw = chip;
- regl->info = &local_regulator_info[n];
+ regl->info = &rinfo[n];
regl->desc = regl->info->desc;
regl->desc.type = REGULATOR_VOLTAGE;
regl->desc.owner = THIS_MODULE;
@@ -836,6 +1115,6 @@ static void __exit da9062_regulator_cleanup(void)
/* Module information */
MODULE_AUTHOR("S Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>");
-MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062");
+MODULE_DESCRIPTION("REGULATOR device driver for Dialog DA9062 and DA9061");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da9062-regulators");
--
end-of-patch for PATCH V5
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V5 6/8] watchdog: da9062/61: watchdog driver
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: Guenter Roeck, LINUX-KERNEL, LINUX-WATCHDOG, Wim Van Sebroeck
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, LINUX-INPUT,
LINUX-PM, Lee Jones, Liam Girdwood, Mark Brown, Mark Rutland,
Rob Herring, Support Opensource, Zhang Rui
In-Reply-To: <cover.1481828921.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
The of_device_id match array is added to support "dlg,da9062-watchdog"
as a valid .compatible string. A MODULE_DEVICE_TABLE() macro is added.
This patch assumes the use of a DA9062 fallback compatible string for the
DTS to pick up the DA9062 device driver for use with the DA9061 watchdog
hardware
Copyright header is updated to add DA9061 in its description and the module
description macro is extended to include DA9061.
Kconfig is updated to reflect support for DA9061/62.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.9
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 7/9] to [PATCH V4 6/8]
- Added reviewed by Guenter Roeck
v2 -> v3
- Patch renamed from [PATCH V2 08/10] to [PATCH V3 7/9]
- Removal of match->data and of_match_node search. There is only one
compatible string now. and delete the .data = &da9062_watchdog_info
association in the struct of_device_id compatible table.
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions:
da9062_wdt.ko platform:da9062_watchdog
of:N*T*Cdlg,da9062_watchdogC*
of:N*T*Cdlg,da9062_watchdog
v1 -> v2
- Patch renamed from [PATCH V1 04/10] to [PATCH V2 08/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Removal of the DA9061 compatible entries for this device driver.
- Additional explanation in the patch description for the use of a
fall-back compatible DTS string
Hi,
There are no code changes to this patch compared to the previous
submission in [PATCH V3 7/9]. The differences are in the patch version
rename and Reviewed-by tag.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/watchdog/Kconfig | 4 ++--
drivers/watchdog/da9062_wdt.c | 12 ++++++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3eb58cb..bb4e7dd8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -104,11 +104,11 @@ config DA9063_WATCHDOG
This driver can be built as a module. The module name is da9063_wdt.
config DA9062_WATCHDOG
- tristate "Dialog DA9062 Watchdog"
+ tristate "Dialog DA9062/61 Watchdog"
depends on MFD_DA9062
select WATCHDOG_CORE
help
- Support for the watchdog in the DA9062 PMIC.
+ Support for the watchdog in the DA9062 and DA9061 PMICs.
This driver can be built as a module. The module name is da9062_wdt.
diff --git a/drivers/watchdog/da9062_wdt.c b/drivers/watchdog/da9062_wdt.c
index 7386111..a02cee6 100644
--- a/drivers/watchdog/da9062_wdt.c
+++ b/drivers/watchdog/da9062_wdt.c
@@ -1,5 +1,5 @@
/*
- * da9062_wdt.c - WDT device driver for DA9062
+ * Watchdog device driver for DA9062 and DA9061 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -188,6 +188,13 @@ static int da9062_wdt_set_timeout(struct watchdog_device *wdd,
.set_timeout = da9062_wdt_set_timeout,
};
+static const struct of_device_id da9062_compatible_id_table[] = {
+ { .compatible = "dlg,da9062-watchdog", },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_id_table);
+
static int da9062_wdt_probe(struct platform_device *pdev)
{
int ret;
@@ -244,11 +251,12 @@ static int da9062_wdt_remove(struct platform_device *pdev)
.remove = da9062_wdt_remove,
.driver = {
.name = "da9062-watchdog",
+ .of_match_table = da9062_compatible_id_table,
},
};
module_platform_driver(da9062_wdt_driver);
MODULE_AUTHOR("S Twiss <stwiss.opensource@diasemi.com>");
-MODULE_DESCRIPTION("WDT device driver for Dialog DA9062");
+MODULE_DESCRIPTION("WDT device driver for Dialog DA9062 and DA9061");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:da9062-watchdog");
--
end-of-patch for PATCH V5
^ permalink raw reply related
* [PATCH V5 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: Eduardo Valentin, LINUX-KERNEL, LINUX-PM, Zhang Rui
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-WATCHDOG, Lee Jones, Liam Girdwood, Lukasz Luba, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck
In-Reply-To: <cover.1481828921.git.stwiss.opensource@diasemi.com>
From: Steve Twiss <stwiss.opensource@diasemi.com>
Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
If the PMIC's internal junction temperature rises above T_WARN (125 degC)
an interrupt is issued. This T_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.
The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).
This scheme is provided as an example. It would be expected that any
final implementation will also include a notify() function and any of these
settings could be altered to match the application where appropriate.
When over-temperature is reached, the interrupt from the DA9061/2 will be
repeatedly triggered. The IRQ is therefore disabled when the first
over-temperature event happens and the status bit is polled using a
work-queue until it becomes false.
This strategy is designed to allow the periodic transmission of uevents
(HOT trip point) as the first level of temperature supervision method. It
is intended for non-invasive temperature control, where the necessary
measures for cooling the system down are left to the host software. Once
the temperature falls again, the IRQ is re-enabled so a new critical
over-temperature event can be detected.
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
---
This patch applies against linux-next and v4.9
v4 -> v5
- Rebased from v4.8 to v4.9
- Updates from comments by Eduardo Valentin
- Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
thermal core polling-delay-passive as part of the device tree
initialisation
- Change to the commit message content and device driver source code to
include an explanation of the repeated uevent strategy for monitoring
over-temperature
- Rename warning threshold name from TEMP_WARN to T_WARN to match the
latest datasheet naming convention
- Added reviewed-by Lukasz Luba to commit message
v3 -> v4
- Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
- Reordering of cancel_delayed_work_sync() in remove function
- dev_warn() message for out-of-range polling period requests
- Explanatory comment for expected values defined for
DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
MIN_POLLING_MS_PERIOD
v2 -> v3
- Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
v1 -> v2
- Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- List the header files in alphabetical order
- Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
copyright "GNU Public License v2 or later" option in the header
comment for this file. See the allowed identifiers in the file
include/linux/module.h +170
- Remove notify function "da9062_thermal_notify" function.
- MODULE_AUTHOR() macros removes Company Name and just gives Name in
accordance with include/linux/module.h +200
- Remove the compatible "dlg,da9061-thermal" option in the of_device_id
struct table. This patch now assumes the use of a DA9062 fallback
compatible string in the DTS when using the DA9061 thermal component
of the DA9061 device.
- Re-ordered some assignments earlier in the probe() for thermal->hw,
thermal->polling_period, thermal->mode, thermal->dev
- Added further information in the patch description to explain the use
of the device driver's built-in work-queue.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 314 +++++++++++++++++++++++++++++++++++++++
3 files changed, 325 insertions(+)
create mode 100644 drivers/thermal/da9062-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a13541b..400d15c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -292,6 +292,16 @@ config DB8500_CPUFREQ_COOLING
bound cpufreq cooling device turns active to set CPU frequency low to
cool down the CPU.
+config DA9062_THERMAL
+ tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+ depends on MFD_DA9062
+ depends on OF
+ help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
config INTEL_POWERCLAMP
tristate "Intel PowerClamp idle injection driver"
depends on THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index c92eb22..f7783b3 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += db8500_cpufreq_cooling.o
+obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
obj-$(CONFIG_INTEL_SOC_DTS_IOSF_CORE) += intel_soc_dts_iosf.o
diff --git a/drivers/thermal/da9062-thermal.c b/drivers/thermal/da9062-thermal.c
new file mode 100644
index 0000000..52a095d
--- /dev/null
+++ b/drivers/thermal/da9062-thermal.c
@@ -0,0 +1,314 @@
+/*
+ * Thermal device driver for DA9062 and DA9061
+ * Copyright (C) 2016 Dialog Semiconductor Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/* When over-temperature is reached, an interrupt from the device will be
+ * triggered. Following this event the interrupt will be disabled and
+ * periodic transmission of uevents (HOT trip point) should define the
+ * first level of temperature supervision. It is expected that any final
+ * implementation of the thermal driver will include a .notify() function
+ * to implement these uevents to userspace.
+ *
+ * These uevents are intended to indicate non-invasive temperature control
+ * of the system, where the necessary measures for cooling are the
+ * responsibility of the host software. Once the temperature falls again,
+ * the IRQ is re-enabled so the start of a new over-temperature event can
+ * be detected without constant software monitoring.
+ */
+
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+#include <linux/workqueue.h>
+
+#include <linux/mfd/da9062/core.h>
+#include <linux/mfd/da9062/registers.h>
+
+/* Minimum, maximum and default polling millisecond periods are provided
+ * here as an example. It is expected that any final implementation to also
+ * include a modification of these settings to match the required
+ * application.
+ */
+#define DA9062_DEFAULT_POLLING_MS_PERIOD 3000
+#define DA9062_MAX_POLLING_MS_PERIOD 10000
+#define DA9062_MIN_POLLING_MS_PERIOD 1000
+
+#define DA9062_MILLI_CELSIUS(t) ((t)*1000)
+
+struct da9062_thermal_config {
+ const char *name;
+};
+
+struct da9062_thermal {
+ struct da9062 *hw;
+ struct delayed_work work;
+ struct thermal_zone_device *zone;
+ enum thermal_device_mode mode;
+ struct mutex lock;
+ int temperature;
+ int irq;
+ const struct da9062_thermal_config *config;
+ struct device *dev;
+};
+
+static void da9062_thermal_poll_on(struct work_struct *work)
+{
+ struct da9062_thermal *thermal = container_of(work,
+ struct da9062_thermal,
+ work.work);
+ unsigned int val;
+ int ret;
+
+ /* clear E_TEMP */
+ ret = regmap_write(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ DA9062AA_E_TEMP_MASK);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot clear the TJUNC temperature status\n");
+ goto err_enable_irq;
+ }
+
+ /* Now read E_TEMP again: it is acting like a status bit.
+ * If over-temperature, then this status will be true.
+ * If not over-temperature, this status will be false.
+ */
+ ret = regmap_read(thermal->hw->regmap,
+ DA9062AA_EVENT_B,
+ &val);
+ if (ret < 0) {
+ dev_err(thermal->dev,
+ "Cannot check the TJUNC temperature status\n");
+ goto err_enable_irq;
+ } else {
+ if (val & DA9062AA_E_TEMP_MASK) {
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(125);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone,
+ THERMAL_EVENT_UNSPECIFIED);
+
+ schedule_delayed_work(&thermal->work,
+ msecs_to_jiffies(thermal->zone->passive_delay));
+ return;
+ } else {
+ mutex_lock(&thermal->lock);
+ thermal->temperature = DA9062_MILLI_CELSIUS(0);
+ mutex_unlock(&thermal->lock);
+ thermal_zone_device_update(thermal->zone,
+ THERMAL_EVENT_UNSPECIFIED);
+ }
+ }
+
+err_enable_irq:
+ enable_irq(thermal->irq);
+}
+
+static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
+{
+ struct da9062_thermal *thermal = data;
+
+ disable_irq_nosync(thermal->irq);
+ schedule_delayed_work(&thermal->work, 0);
+
+ return IRQ_HANDLED;
+}
+
+static int da9062_thermal_get_mode(struct thermal_zone_device *z,
+ enum thermal_device_mode *mode)
+{
+ struct da9062_thermal *thermal = z->devdata;
+ *mode = thermal->mode;
+ return 0;
+}
+
+static int da9062_thermal_get_trip_type(struct thermal_zone_device *z,
+ int trip,
+ enum thermal_trip_type *type)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *type = THERMAL_TRIP_HOT;
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_trip_temp(struct thermal_zone_device *z,
+ int trip,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ switch (trip) {
+ case 0:
+ *temp = DA9062_MILLI_CELSIUS(125);
+ break;
+ default:
+ dev_err(thermal->dev,
+ "Driver does not support more than 1 trip-wire\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int da9062_thermal_get_temp(struct thermal_zone_device *z,
+ int *temp)
+{
+ struct da9062_thermal *thermal = z->devdata;
+
+ mutex_lock(&thermal->lock);
+ *temp = thermal->temperature;
+ mutex_unlock(&thermal->lock);
+
+ return 0;
+}
+
+static struct thermal_zone_device_ops da9062_thermal_ops = {
+ .get_temp = da9062_thermal_get_temp,
+ .get_mode = da9062_thermal_get_mode,
+ .get_trip_type = da9062_thermal_get_trip_type,
+ .get_trip_temp = da9062_thermal_get_trip_temp,
+};
+
+static const struct da9062_thermal_config da9062_config = {
+ .name = "da9062-thermal",
+};
+
+static const struct of_device_id da9062_compatible_reg_id_table[] = {
+ { .compatible = "dlg,da9062-thermal", .data = &da9062_config },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, da9062_compatible_reg_id_table);
+
+static int da9062_thermal_probe(struct platform_device *pdev)
+{
+ struct da9062 *chip = dev_get_drvdata(pdev->dev.parent);
+ struct da9062_thermal *thermal;
+ unsigned int pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ const struct of_device_id *match;
+ int ret = 0;
+
+ match = of_match_node(da9062_compatible_reg_id_table,
+ pdev->dev.of_node);
+ if (!match)
+ return -ENXIO;
+
+ if (pdev->dev.of_node) {
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "polling-delay-passive",
+ &pp_tmp)) {
+ if (pp_tmp < DA9062_MIN_POLLING_MS_PERIOD ||
+ pp_tmp > DA9062_MAX_POLLING_MS_PERIOD) {
+ dev_warn(&pdev->dev,
+ "Out-of-range polling period %d ms\n",
+ pp_tmp);
+ pp_tmp = DA9062_DEFAULT_POLLING_MS_PERIOD;
+ }
+ }
+ }
+
+ thermal = devm_kzalloc(&pdev->dev, sizeof(struct da9062_thermal),
+ GFP_KERNEL);
+ if (!thermal) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ thermal->config = match->data;
+ thermal->hw = chip;
+ thermal->mode = THERMAL_DEVICE_ENABLED;
+ thermal->dev = &pdev->dev;
+
+ INIT_DELAYED_WORK(&thermal->work, da9062_thermal_poll_on);
+ mutex_init(&thermal->lock);
+
+ thermal->zone = thermal_zone_device_register(thermal->config->name,
+ 1, 0, thermal,
+ &da9062_thermal_ops, NULL, pp_tmp,
+ 0);
+ if (IS_ERR(thermal->zone)) {
+ dev_err(&pdev->dev, "Cannot register thermal zone device\n");
+ ret = PTR_ERR(thermal->zone);
+ goto err;
+ }
+
+ dev_dbg(&pdev->dev,
+ "TJUNC temperature polling period set at %d ms\n",
+ thermal->zone->passive_delay);
+
+ ret = platform_get_irq_byname(pdev, "THERMAL");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get platform IRQ.\n");
+ goto err_zone;
+ }
+ thermal->irq = ret;
+
+ ret = request_threaded_irq(thermal->irq, NULL,
+ da9062_thermal_irq_handler,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ "THERMAL", thermal);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to request thermal device IRQ.\n");
+ goto err_zone;
+ }
+
+ platform_set_drvdata(pdev, thermal);
+ return 0;
+
+err_zone:
+ thermal_zone_device_unregister(thermal->zone);
+err:
+ return ret;
+}
+
+static int da9062_thermal_remove(struct platform_device *pdev)
+{
+ struct da9062_thermal *thermal = platform_get_drvdata(pdev);
+
+ free_irq(thermal->irq, thermal);
+ cancel_delayed_work_sync(&thermal->work);
+ thermal_zone_device_unregister(thermal->zone);
+ return 0;
+}
+
+static struct platform_driver da9062_thermal_driver = {
+ .probe = da9062_thermal_probe,
+ .remove = da9062_thermal_remove,
+ .driver = {
+ .name = "da9062-thermal",
+ .of_match_table = da9062_compatible_reg_id_table,
+ },
+};
+
+module_platform_driver(da9062_thermal_driver);
+
+MODULE_AUTHOR("Steve Twiss");
+MODULE_DESCRIPTION("Thermal TJUNC device driver for Dialog DA9062 and DA9061");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:da9062-thermal");
--
end-of-patch for PATCH V5
^ permalink raw reply related
* [PATCH V5 0/8] da9061: DA9061 driver submission
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG, Lee Jones,
Liam Girdwood, Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Steve Twiss, Wim Van Sebroeck, Zhang Rui
Cc: Support Opensource
From: Steve Twiss <stwiss.opensource@diasemi.com>
This patch set adds support for the Dialog DA9061 Power Management IC.
Support is made by altering the existing DA9062 device driver, where
appropriate.
In this patch set the following is provided:
[PATCH V5 1/8] Binding for watchdog
[PATCH V5 2/8] Binding for thermal supervisor
[PATCH V5 3/8] Binding for MFD and regulators
[PATCH V5 4/8] MFD core support
[PATCH V5 5/8] BUCKs and LDOs
[PATCH V5 6/8] Watchdog
[PATCH V5 7/8] PMIC temperature monitoring
[PATCH V5 8/8] MAINTAINERS update
Some previous patches from this set have been applied already:
Onkey binding -- https://lkml.org/lkml/2016/11/8/958
Onkey driver -- https://lkml.org/lkml/2016/10/26/1169
This patch applies against linux-next and v4.9
Thank you,
Steve Twiss, Dialog Semiconductor Ltd.
Steve Twiss (8):
Documentation: devicetree: watchdog: da9062/61 watchdog timer binding
Documentation: devicetree: thermal: da9062/61 TJUNC temperature
binding
Documentation: devicetree: mfd: da9062/61 MFD binding
mfd: da9061: MFD core support
regulator: da9061: BUCK and LDO regulator driver
watchdog: da9062/61: watchdog driver
thermal: da9062/61: Thermal junction temperature monitoring driver
MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search
terms
Documentation/devicetree/bindings/mfd/da9062.txt | 49 ++-
.../devicetree/bindings/thermal/da9062-thermal.txt | 37 ++
.../devicetree/bindings/watchdog/da9062-wdt.txt | 23 ++
MAINTAINERS | 4 +
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 424 ++++++++++++++++++++-
drivers/regulator/Kconfig | 4 +-
drivers/regulator/da9062-regulator.c | 301 ++++++++++++++-
drivers/thermal/Kconfig | 10 +
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 314 +++++++++++++++
drivers/watchdog/Kconfig | 4 +-
drivers/watchdog/da9062_wdt.c | 12 +-
include/linux/mfd/da9062/core.h | 27 +-
include/linux/mfd/da9062/registers.h | 2 +
15 files changed, 1168 insertions(+), 49 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/da9062-thermal.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/da9062-wdt.txt
create mode 100644 drivers/thermal/da9062-thermal.c
--
end-of-patch for PATCH V5
^ permalink raw reply
* [PATCH V5 8/8] MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms
From: Steve Twiss @ 2016-12-15 19:08 UTC (permalink / raw)
To: Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, Mark Rutland,
Rob Herring, Wim Van Sebroeck, Zhang Rui
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource
In-Reply-To: <cover.1481828921.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Hi,
Dialog Semiconductor support would like to add to the MAINTAINERS search
terms. This update will allow us to follow files for device tree bindings
and source code relating to input onkey drivers, chip thermal monitoring
and watchdog timers.
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.9
v4 -> v5
- NO CODE CHANGE
- Rebased from v4.8 to v4.9
v3 -> v4
- NO CODE CHANGE
- Patch renamed from [PATCH V3 9/9] to [PATCH V4 8/8]
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 10/10] to [PATCH V3 9/9]
v1 -> v2
- NO CODE CHANGE
Hi,
This patch depends on acceptance of the following from this patch set:
- [PATCH V5 7/8] PMIC temperature monitoring
and also from the following binding file changes:
- Binding for onkey (already applied by Dmitry Torokhov)
- [PATCH V5 1/8] Binding for watchdog
- [PATCH V5 2/8] Binding for thermal
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 63cefa6..2d4b0c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3814,7 +3814,10 @@ W: http://www.dialog-semiconductor.com/products
S: Supported
F: Documentation/hwmon/da90??
F: Documentation/devicetree/bindings/mfd/da90*.txt
+F: Documentation/devicetree/bindings/input/da90??-onkey.txt
+F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt
F: Documentation/devicetree/bindings/regulator/da92*.txt
+F: Documentation/devicetree/bindings/watchdog/da92??-wdt.txt
F: Documentation/devicetree/bindings/sound/da[79]*.txt
F: drivers/gpio/gpio-da90??.c
F: drivers/hwmon/da90??-hwmon.c
@@ -3829,6 +3832,7 @@ F: drivers/power/supply/da9052-battery.c
F: drivers/power/supply/da91??-*.c
F: drivers/regulator/da903x.c
F: drivers/regulator/da9???-regulator.[ch]
+F: drivers/thermal/da90??-thermal.c
F: drivers/rtc/rtc-da90??.c
F: drivers/video/backlight/da90??_bl.c
F: drivers/watchdog/da90??_wdt.c
--
end-of-patch for PATCH V5
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2016-12-15 19:33 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, linux, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <CAOAejn0Ej90amOZUC2wGNBsTAZVmcqEaViV1-TeoaspiADBkkg@mail.gmail.com>
Hello Cedric,
On Thu, Dec 15, 2016 at 04:26:25PM +0100, M'boumba Cedric Madianga wrote:
> >> +static struct platform_driver stm32f4_i2c_driver = {
> >> + .driver = {
> >> + .name = "stm32f4-i2c",
> >> + .of_match_table = stm32f4_i2c_match,
> >
> > Is this needed?
> Without of_match_table, I could not match an I2C device instance from
> DT with this driver.
> So maybe, there is a misunderstanding.
> Could you please clarify your question ?
I thought (but I could be wrong) that if the driver is called
"stm32f4-i2c", it is used to match "st,stm32f4-i2c" even without
.of_match_table. If this doesn't work, please disregard my question.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v6 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-12-15 19:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree, Alexandre Torgue, linux-kernel, Linus Walleij,
Patrice Chotard, linux, Rob Herring, linux-i2c, Maxime Coquelin,
M'boumba Cedric Madianga, linux-arm-kernel
In-Reply-To: <20161215193307.436sggu4zy4zezoe@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]
> I thought (but I could be wrong) that if the driver is called
> "stm32f4-i2c", it is used to match "st,stm32f4-i2c" even without
> .of_match_table. If this doesn't work, please disregard my question.
This currently works only for *i2c client drivers*, it never did for i2c
adapters. And even for clients, this behaviour is going to be deprecated
somewhen. There are people working on it...
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 2/5] i2c: Add STM32F4 I2C driver
From: Wolfram Sang @ 2016-12-15 19:42 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: M'boumba Cedric Madianga, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, patrice.chotard-qxv4g6HH51o,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161213092031.d2ax2pnpzzicriel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
> > + if (ret) {
> > + dev_err(i2c_dev->dev, "bus not free\n");
> > + ret = -EBUSY;
>
> I'm not sure if "bus not free" deserves an error message. Wolfram?
I tend to agree. But I never enforced it up to now, never found the time
to double check if I could/should enforce it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/3] bus: simple-pm: add support to pm clocks
From: Bjorn Andersson @ 2016-12-15 22:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Helgaas, Srinivas Kandagatla,
svarbanov-NEYub+7Iv8PQT0dZR+AlfA, linux-pci, Bjorn Helgaas,
Rob Herring,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Geert Uytterhoeven, Kevin Hilman, Simon Horman, Linux PM list
In-Reply-To: <CAMuHMdUJ8Qn=dR_OMob4BO_4RmY5XemTf_UGM_oJ2VYtBa7Jiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue 15 Nov 00:23 PST 2016, Geert Uytterhoeven wrote:
> +cc linux-pm
>
> On Mon, Nov 14, 2016 at 11:14 PM, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > [+cc Geert, Kevin, Simon]
> >
> > On Mon, Nov 14, 2016 at 11:15:53AM +0000, Srinivas Kandagatla wrote:
> >> This patch adds support to pm clocks via device tree, so that the clocks
> >> can be turned on and off during runtime pm. This patch is required for
> >> Qualcomm msm8996 pcie controller which sits on a bus with its own
> >> power-domain and clocks.
> >>
> >> Without this patch the clock associated with the bus are never turned on.
> >>
> >> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> > I don't see a formal maintainer for drivers/bus/simple-pm-bus.c, but I'd
> > like an ack or at least a review from Geert or Simon.
>
> Thanks for letting me know!
>
> >> ---
> >> drivers/bus/simple-pm-bus.c | 13 ++++++++++++-
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> >> index c5eb46c..63b7e8c 100644
> >> --- a/drivers/bus/simple-pm-bus.c
> >> +++ b/drivers/bus/simple-pm-bus.c
> >> @@ -11,6 +11,7 @@
> >> #include <linux/module.h>
> >> #include <linux/of_platform.h>
> >> #include <linux/platform_device.h>
> >> +#include <linux/pm_clock.h>
> >> #include <linux/pm_runtime.h>
> >>
> >>
> >> @@ -22,17 +23,26 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
> >>
> >> pm_runtime_enable(&pdev->dev);
> >>
> >> - if (np)
> >> + if (np) {
> >> + of_pm_clk_add_clks(&pdev->dev);
>
> This should work out-of-the-box (that's the actual purpose of this driver),
> if the platform code that registers your PM Domain would take care
> of registering the clocks needed for PM management of the bus.
>
Hi Geert,
I'm having problems finding any code that would make this work
"out-of-the-box". The DT binding documents a clocks property but I
can't find any code referencing this in the kernel.
I see that Srinivas interpreted your response as that we should fold the
clocks in behind the power-domain, rather than referencing them from the
bus - but this seems awkward and would indicate the DT binding being
wrong. Perhaps I'm just misunderstanding the design here?
Which "platform code" do you refer to, can you help me by pointing me to
the code that handles the zb_clk in the Renesas case?
> Adding of_pm_clk_add_clks() here will start managing all clocks of the bus,
> which may not be wanted on all platforms.
>
It would not be strange to do so in the "simple" implementation for the
bus, allowing custom behavior to be implemented in a more specific
driver for a platform with custom needs.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
From: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
drivers/nfc/trf7970a.c | 42 ++++++++++++++++------
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..9dda879 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,8 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
+
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ crystal_27mhz;
status = "okay";
};
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..2d2a077 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1056,12 +1056,11 @@ static int trf7970a_init(struct trf7970a *trf)
trf->chip_status_ctrl &= ~TRF7970A_CHIP_STATUS_RF_ON;
- ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL, 0);
+ ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL,
+ trf->modulator_sys_clk_ctrl);
if (ret)
goto err_out;
- trf->modulator_sys_clk_ctrl = 0;
-
ret = trf7970a_write(trf, TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS,
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLH_96 |
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLL_32);
@@ -1181,27 +1180,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
switch (tech) {
case NFC_DIGITAL_RF_TECH_106A:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_NFCA;
break;
case NFC_DIGITAL_RF_TECH_106B:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443B_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCB;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_ISO15693:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_15693_SGL_1OF4_2648;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_15693;
break;
default:
@@ -1571,17 +1580,23 @@ static int trf7970a_tg_config_rf_tech(struct trf7970a *trf, int tech)
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_CE |
TRF7970A_ISO_CTRL_NFC_CE_14443A;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xF8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
default:
dev_dbg(trf->dev, "Unsupported rf technology: %d\n", tech);
@@ -2043,6 +2058,11 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ if (of_property_read_bool(np, "crystal_27mhz")) {
+ trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
+ dev_dbg(trf->dev, "trf7970a configure crystal_27mhz\n");
+ }
+
if (of_property_read_bool(np, "en2-rf-quirk"))
trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
--
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
^ permalink raw reply related
* [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mgreer-luAo+O/VEmrlveNOaEYElw, justin-R+k406RtEhcAvxtiuMwx3w,
Geoff Lansberry
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 9dda879..208f045 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- vdd_io_1v8: Set to specify that the trf7970a io voltage should be set to 1.8V
- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
@@ -45,6 +46,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ vdd_io_1v8;
crystal_27mhz;
status = "okay";
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 2d2a077..b4c37ab 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -441,6 +441,7 @@ struct trf7970a {
u8 iso_ctrl_tech;
u8 modulator_sys_clk_ctrl;
u8 special_fcn_reg1;
+ u8 io_ctrl;
unsigned int guard_time;
int technology;
int framing;
@@ -1048,6 +1049,11 @@ static int trf7970a_init(struct trf7970a *trf)
if (ret)
goto err_out;
+ ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
+ trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
+ if (ret)
+ goto err_out;
+
ret = trf7970a_write(trf, TRF7970A_NFC_TARGET_LEVEL, 0);
if (ret)
goto err_out;
@@ -1764,7 +1770,7 @@ static int _trf7970a_tg_listen(struct nfc_digital_dev *ddev, u16 timeout,
goto out_err;
ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
- TRF7970A_REG_IO_CTRL_VRS(0x1));
+ trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
if (ret)
goto out_err;
@@ -2058,6 +2064,11 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ if (of_property_read_bool(np, "vdd_io_1v8")) {
+ trf->io_ctrl = TRF7970A_REG_IO_CTRL_IO_LOW;
+ dev_dbg(trf->dev, "trf7970a config vdd_io_1v8\n");
+ }
+
if (of_property_read_bool(np, "crystal_27mhz")) {
trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_27MHZ;
dev_dbg(trf->dev, "trf7970a configure crystal_27mhz\n");
--
Signed-off-by: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-15 22:30 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Jaret Cantu,
Geoff Lansberry
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
From: Jaret Cantu <jaret.cantu@timesys.com>
Repeated polling attempts cause a NULL dereference error to occur.
This is because the curent state of the trf7970a is reading but
a request has been made to send a command.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
---
drivers/nfc/trf7970a.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index b4c37ab..f96a321 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1493,6 +1493,10 @@ static int trf7970a_send_cmd(struct nfc_digital_dev *ddev,
(trf->state != TRF7970A_ST_IDLE_RX_BLOCKED)) {
dev_err(trf->dev, "%s - Bogus state: %d\n", __func__,
trf->state);
+ if (trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA ||
+ trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA_CONT)
+ trf->ignore_timeout =
+ !cancel_delayed_work(&trf->timeout_work);
ret = -EIO;
goto out_err;
}
--
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
^ permalink raw reply related
* [PATCH 1/3 v2] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Linus Walleij @ 2016-12-15 22:48 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Ivan T . Ivanov, Andy Gross,
Bjorn Andersson, Stephen Boyd, Srinivas Kandagatla
This adds the device tree bindings for the Qualcomm PM8xxx
ADCs. This is based on the existing DT bindings for the
SPMI ADC so there are hopefully no controversial features.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Ivan T. Ivanov <iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
ChangeLog v1->v2:
- Spelling fixes
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
1 file changed, 160 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
new file mode 100644
index 000000000000..3c6bca5b4edf
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -0,0 +1,160 @@
+Qualcomm's PM8xxx voltage XOADC
+
+The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Crystal
+oscillator ADC) encompassing PM8018, PM8038, PM8058, PM8917 and PM8921.
+
+Required properties:
+
+- compatible: should be one of:
+ "qcom,pm8018-adc"
+ "qcom,pm8038-adc"
+ "qcom,pm8058-adc"
+ "qcom,pm8917-adc"
+ "qcom,pm8921-adc"
+
+- reg: should contain the ADC base address in the PMIC, typically
+ 0x197.
+
+The following required properties are standard for IO channels, see
+iio-bindings.txt for more details:
+
+- #address-cells: should be set to <1>
+
+- #size-cells: should be set to <0>
+
+- #io-channel-cells: should be set to <1>
+
+- interrupts: should refer to the parent PMIC interrupt controller
+ and reference the proper ADC interrupt.
+
+Required subnodes:
+
+The ADC channels are configured as subnodes of the ADC. Since some of
+them are used for calibrating the ADC, these nodes are compulsory:
+
+ref_625mv {
+ reg = <0x0c>;
+};
+
+ref_1250mv {
+ reg = <0x0d>;
+};
+
+ref_muxoff {
+ reg = <0x0f>;
+};
+
+These three nodes are used for absolute and ratiometric calibration
+and only need to have these reg values: they are by hardware definition
+1:1 ratio converters that sample 625, 1250 and 0 milliV and create
+an interpolation calibration for all other ADCs.
+
+Optional subnodes: any channels other than channel 0x0c, 0x0d and
+0x0f are optional.
+
+Required channel node properties:
+
+- reg: should contain the hardware channel number in the range
+ 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+
+Optional channel node properties:
+
+- qcom,decimation:
+ Value type: <u32>
+ Definition: This parameter is used to decrease the ADC sampling rate.
+ Quicker measurements can be made by reducing the decimation ratio.
+ Valid values are 512, 1024, 2048, 4096.
+ If the property is not found, a default value of 512 will be used.
+
+- qcom,ratiometric:
+ Value type: <empty>
+ Definition: Channel calibration type. If this property is specified
+ VADC will use the VDD reference (1.8V) and GND for channel
+ calibration. If the property is not found, the channel will be
+ calibrated with the 0.625V and 1.25V reference channels, also
+ known as an absolute calibration.
+
+- qcom,ratiometric-ref:
+ Value type: <u32>
+ Definition: The reference voltage pair when using ratiometric
+ calibration:
+ 0 = XO_IN/XOADC_GND
+ 1 = PMIC_IN/XOADC_GND
+ 2 = PMIC_IN/BMS_CSP
+ 3 (invalid)
+ 4 = XOADC_GND/XOADC_GND
+ 5 = XOADC_VREF/XOADC_GND
+
+Example:
+
+xoadc: xoadc@197 {
+ compatible = "qcom,pm8058-adc";
+ reg = <0x197>;
+ interrupt-parent = <&pm8058>;
+ interrupts = <76 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ vcoin {
+ reg = <0x00>;
+ };
+ vbat {
+ reg = <0x01>;
+ };
+ dcin {
+ reg = <0x02>;
+ };
+ ichg {
+ reg = <0x03>;
+ };
+ vph_pwr {
+ reg = <0x04>;
+ };
+ mpp5 {
+ reg = <0x05>;
+ };
+ mpp6 {
+ reg = <0x06>;
+ };
+ mpp7 {
+ reg = <0x07>;
+ };
+ mpp8 {
+ reg = <0x08>;
+ };
+ mpp9 {
+ reg = <0x09>;
+ };
+ usb_vbus {
+ reg = <0x0a>;
+ };
+ die_temp {
+ reg = <0x0b>;
+ };
+ ref_625mv {
+ reg = <0x0c>;
+ };
+ ref_1250mv {
+ reg = <0x0d>;
+ };
+ ref_325mv {
+ reg = <0x0e>;
+ };
+ ref_muxoff {
+ reg = <0x0f>;
+ };
+};
+
+
+/* IIO client node */
+iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&xoadc 0x01>, /* Battery */
+ <&xoadc 0x02>, /* DC in (charger) */
+ <&xoadc 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x0b>, /* Die temperature */
+ <&xoadc 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x0e>; /* Reference voltage 0.325V */
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH linux v1 4/4] arm: dts: Add dt-binding to support seven segment display on zaius
From: Linus Walleij @ 2016-12-15 23:07 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Arnd Bergmann, Mark Rutland,
Jaghathiswari Rankappagounder Natarajan,
devicetree@vger.kernel.org, Greg KH, OpenBMC Maillist,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
Rob Herring, Joel Stanley, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161214114051.GC14217@n2100.armlinux.org.uk>
On Wed, Dec 14, 2016 at 12:40 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> Looking at this more, it's a SPI driver, presumably because the first
> case where it appeared was on a SPI bus.
>
> However, it's not a SPI device as such, it's a piece of standard,
> general purpose logic that's been around for many years, pre-dating
> the SPI bus.
Indeed.
> I think a much more sensible approach would be to turn the GPIO side
> of the 74x164 driver into a library, which can be re-used by multiple
> bus-specific drivers - one for SPI which allows it to be used in its
> current form, one for our platform bus which takes the GPIO lines for
> the data, clock and clear signals.
>
> I also don't see why they shouldn't use the same compatible - they're
> the same _device_ at the end of the day, just wired up differently.
> It makes the binding documentation a little fun wrt what are required
> and optional properties, but nothing that shouldn't be too difficult.
I agree on both accounts.
Sorry for not seeing this in the first place, I was well aware that this
is a standard component and may be connected in a myriad of ways,
so I should have known better :(
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cyrille Pitchen @ 2016-12-15 23:15 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse
In-Reply-To: <1481557252-13656-2-git-send-email-clg@kaod.org>
Hi Cedric,
Le 12/12/2016 à 16:40, Cédric Le Goater a écrit :
> This driver adds mtd support for the Aspeed AST2500 SoC static memory
> controllers :
>
> * Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . supports SPI type flash memory (CE0-CE1)
> . CE2 can be of NOR type flash but this is not supported by the
> driver
>
> * SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . supports SPI type flash memory
>
> Each controller has a memory range on which it maps its flash module
> slaves. Each slave is assigned a memory window for its mapping that
> can be changed at bootime with the Segment Address Register.
>
> Each SPI flash slave can then be accessed in two modes: Command and
> User. When in User mode, accesses to the memory segment of the slaves
> are translated in SPI transfers. When in Command mode, the HW
> generates the SPI commands automatically and the memory segment is
> accessed as if doing a MMIO.
>
> Currently, only the User mode is supported. Command mode needs a
> little more work to check that the memory window on the AHB bus fits
> the module size.
>
> Based on previous work from Milton D. Miller II <miltonm@us.ibm.com>
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
> ---
>
> Changes since v3:
> - reworked IO routines to use io{read,write}32_rep
> - changed config option to SPI_ASPEED_SMC
> - fixed aspeed_smc_chip_setup_init() returned value
> - merged the use of the "label" property"
>
> drivers/mtd/spi-nor/Kconfig | 10 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/aspeed-smc.c | 719 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 730 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 4a682ee0f632..42168e9d6097 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -29,6 +29,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS
> Please note that some tools/drivers/filesystems may not work with
> 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
>
> +config SPI_ASPEED_SMC
> + tristate "Aspeed flash controllers in SPI mode"
> + depends on ARCH_ASPEED || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + help
> + This enables support for the Firmware Memory controller (FMC)
> + in the Aspeed AST2500 SoC when attached to SPI NOR chips,
> + and support for the SPI flash memory controller (SPI) for
> + the host firmware. The implementation only supports SPI NOR.
> +
> config SPI_ATMEL_QUADSPI
> tristate "Atmel Quad SPI Controller"
> depends on ARCH_AT91 || (ARM && COMPILE_TEST)
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 121695e83542..6ff64bc7fa0e 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
> +obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
> obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o
> obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
> obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o
> diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
> new file mode 100644
> index 000000000000..2667ab7aeb9b
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/aspeed-smc.c
> @@ -0,0 +1,719 @@
> +/*
> + * ASPEED Static Memory Controller driver
> + *
> + * Copyright (c) 2015-2016, IBM Corporation.
> + *
> + * 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/bug.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/spi-nor.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +#include <linux/sysfs.h>
> +
> +#define DEVICE_NAME "aspeed-smc"
> +
> +/*
> + * The driver only support SPI flash
> + */
> +enum aspeed_smc_flash_type {
> + smc_type_nor = 0,
> + smc_type_nand = 1,
> + smc_type_spi = 2,
> +};
> +
> +struct aspeed_smc_chip;
> +
> +struct aspeed_smc_info {
> + u32 maxsize; /* maximum size of chip window */
> + u8 nce; /* number of chip enables */
> + bool hastype; /* flash type field exists in config reg */
> + u8 we0; /* shift for write enable bit for CE0 */
> + u8 ctl0; /* offset in regs of ctl for CE0 */
> +
> + void (*set_4b)(struct aspeed_smc_chip *chip);
> +};
> +
> +static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
> +
> +static const struct aspeed_smc_info fmc_2500_info = {
> + .maxsize = 256 * 1024 * 1024,
> + .nce = 3,
> + .hastype = true,
> + .we0 = 16,
> + .ctl0 = 0x10,
> + .set_4b = aspeed_smc_chip_set_4b,
> +};
> +
> +static const struct aspeed_smc_info spi_2500_info = {
> + .maxsize = 128 * 1024 * 1024,
> + .nce = 2,
> + .hastype = false,
> + .we0 = 16,
> + .ctl0 = 0x10,
> + .set_4b = aspeed_smc_chip_set_4b,
> +};
> +
> +enum aspeed_smc_ctl_reg_value {
> + smc_base, /* base value without mode for other commands */
> + smc_read, /* command reg for (maybe fast) reads */
> + smc_write, /* command reg for writes */
> + smc_max,
> +};
> +
> +struct aspeed_smc_controller;
> +
> +struct aspeed_smc_chip {
> + int cs;
> + struct aspeed_smc_controller *controller;
> + void __iomem *ctl; /* control register */
> + void __iomem *ahb_base; /* base of chip window */
> + u32 ctl_val[smc_max]; /* control settings */
> + enum aspeed_smc_flash_type type; /* what type of flash */
> + struct spi_nor nor;
> +};
> +
> +struct aspeed_smc_controller {
> + struct device *dev;
> +
> + struct mutex mutex; /* controller access mutex */
> + const struct aspeed_smc_info *info; /* type info of controller */
> + void __iomem *regs; /* controller registers */
> + void __iomem *ahb_base; /* per-chip windows resource */
> +
> + struct aspeed_smc_chip *chips[0]; /* pointers to attached chips */
> +};
> +
> +/*
> + * SPI Flash Configuration Register (AST2500 SPI)
> + * or
> + * Type setting Register (AST2500 FMC).
> + * CE0 and CE1 can only be of type SPI. CE2 can be of type NOR but the
> + * driver does not support it.
> + */
> +#define CONFIG_REG 0x0
> +#define CONFIG_DISABLE_LEGACY BIT(31) /* 1 */
> +
> +#define CONFIG_CE2_WRITE BIT(18)
> +#define CONFIG_CE1_WRITE BIT(17)
> +#define CONFIG_CE0_WRITE BIT(16)
> +
> +#define CONFIG_CE2_TYPE BIT(4) /* AST2500 FMC only */
> +#define CONFIG_CE1_TYPE BIT(2) /* AST2500 FMC only */
> +#define CONFIG_CE0_TYPE BIT(0) /* AST2500 FMC only */
> +
> +/*
> + * CE Control Register
> + */
> +#define CE_CONTROL_REG 0x4
> +
> +/*
> + * CEx Control Register
> + */
> +#define CONTROL_AAF_MODE BIT(31)
> +#define CONTROL_IO_MODE_MASK GENMASK(30, 28)
> +#define CONTROL_IO_DUAL_DATA BIT(29)
> +#define CONTROL_IO_DUAL_ADDR_DATA (BIT(29) | BIT(28))
> +#define CONTROL_IO_QUAD_DATA BIT(30)
> +#define CONTROL_IO_QUAD_ADDR_DATA (BIT(30) | BIT(28))
> +#define CONTROL_CE_INACTIVE_SHIFT 24
> +#define CONTROL_CE_INACTIVE_MASK GENMASK(27, \
> + CONTROL_CE_INACTIVE_SHIFT)
> +/* 0 = 16T ... 15 = 1T T=HCLK */
> +#define CONTROL_COMMAND_SHIFT 16
> +#define CONTROL_DUMMY_COMMAND_OUT BIT(15)
> +#define CONTROL_IO_DUMMY_HI BIT(14)
> +#define CONTROL_IO_DUMMY_HI_SHIFT 14
> +#define CONTROL_CLK_DIV4 BIT(13) /* others */
> +#define CONTROL_RW_MERGE BIT(12)
> +#define CONTROL_IO_DUMMY_LO_SHIFT 6
> +#define CONTROL_IO_DUMMY_LO GENMASK(7, \
> + CONTROL_IO_DUMMY_LO_SHIFT)
> +#define CONTROL_IO_DUMMY_MASK (CONTROL_IO_DUMMY_HI | \
> + CONTROL_IO_DUMMY_LO)
> +#define CONTROL_IO_DUMMY_SET(dummy) \
> + (((((dummy) >> 2) & 0x1) << CONTROL_IO_DUMMY_HI_SHIFT) | \
> + (((dummy) & 0x3) << CONTROL_IO_DUMMY_LO_SHIFT))
> +
> +#define CONTROL_CLOCK_FREQ_SEL_SHIFT 8
> +#define CONTROL_CLOCK_FREQ_SEL_MASK GENMASK(11, \
> + CONTROL_CLOCK_FREQ_SEL_SHIFT)
> +#define CONTROL_LSB_FIRST BIT(5)
> +#define CONTROL_CLOCK_MODE_3 BIT(4)
> +#define CONTROL_IN_DUAL_DATA BIT(3)
> +#define CONTROL_CE_STOP_ACTIVE_CONTROL BIT(2)
> +#define CONTROL_COMMAND_MODE_MASK GENMASK(1, 0)
> +#define CONTROL_COMMAND_MODE_NORMAL 0
> +#define CONTROL_COMMAND_MODE_FREAD 1
> +#define CONTROL_COMMAND_MODE_WRITE 2
> +#define CONTROL_COMMAND_MODE_USER 3
> +
> +#define CONTROL_KEEP_MASK \
> + (CONTROL_AAF_MODE | CONTROL_CE_INACTIVE_MASK | CONTROL_CLK_DIV4 | \
> + CONTROL_IO_DUMMY_MASK | CONTROL_CLOCK_FREQ_SEL_MASK | \
> + CONTROL_LSB_FIRST | CONTROL_CLOCK_MODE_3)
> +
> +/*
> + * The Segment Register uses a 8MB unit to encode the start address
> + * and the end address of the mapping window of a flash SPI slave :
> + *
> + * | byte 1 | byte 2 | byte 3 | byte 4 |
> + * +--------+--------+--------+--------+
> + * | end | start | 0 | 0 |
> + */
> +#define SEGMENT_ADDR_REG0 0x30
> +#define SEGMENT_ADDR_START(_r) ((((_r) >> 16) & 0xFF) << 23)
> +#define SEGMENT_ADDR_END(_r) ((((_r) >> 24) & 0xFF) << 23)
> +
> +/*
> + * In user mode all data bytes read or written to the chip decode address
> + * range are transferred to or from the SPI bus. The range is treated as a
> + * fifo of arbitratry 1, 2, or 4 byte width but each write has to be aligned
> + * to its size. The address within the multiple 8kB range is ignored when
> + * sending bytes to the SPI bus.
> + *
> + * On the arm architecture, as of Linux version 4.3, memcpy_fromio and
> + * memcpy_toio on little endian targets use the optimized memcpy routines
> + * that were designed for well behavied memory storage. These routines
> + * have a stutter if the source and destination are not both word aligned,
> + * once with a duplicate access to the source after aligning to the
> + * destination to a word boundary, and again with a duplicate access to
> + * the source when the final byte count is not word aligned.
> + *
> + * When writing or reading the fifo this stutter discards data or sends
> + * too much data to the fifo and can not be used by this driver.
> + *
> + * While the low level io string routines that implement the insl family do
> + * the desired accesses and memory increments, the cross architecture io
> + * macros make them essentially impossible to use on a memory mapped address
> + * instead of a a token from the call to iomap of an io port.
> + *
> + * These fifo routines use readl and friends to a constant io port and update
> + * the memory buffer pointer and count via explicit code. The final updates
> + * to len are optimistically suppressed.
> + */
> +static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
> + size_t len)
> +{
> + if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
> + IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t)) &&
> + IS_ALIGNED(len, sizeof(u32))) {
> + ioread32_rep(src, buf, len >> 2);
> + } else {
> + ioread8_rep(src, buf, len);
> + }
> + return 0;
> +}
> +
Maybe It might be something like:
size_t offset = 0;
if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
ioread32_rep(src, buf, len >> 2);
offset = len & ~0x3;
len -= offset;
}
ioread8_rep(src, (const u8 *)buf + offset, len);
I assume the Aspeed SPI controller allows to read as much 32-bit words
as possible before reading the remaining bytes.
This is just a suggested optimization, no need to use it if you don't
want to.
In v3, with readl()/readb(), you used to increment both src and buf in
your while() loop but now with ioreadX_rep() only buf is incremented: it
always reads from src without incrementing this latest address.
I guess it means that the Aspeed SPI controller doesn't care of the
actual value of src as long as it lays inside the chip address range.
This is what you explain in the 1st paragraph of the comment, isn't it?
> +static int aspeed_smc_write_to_ahb(void __iomem *dst, const void *buf,
> + size_t len)
> +{
> + if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
> + IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t)) &&
> + IS_ALIGNED(len, sizeof(u32))) {
> + iowrite32_rep(dst, buf, len >> 2);
> + } else {
> + iowrite8_rep(dst, buf, len);
> + }
> + return 0;
> +}
> +
> +static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
> +{
> + return BIT(chip->controller->info->we0 + chip->cs);
> +}
> +
> +static void aspeed_smc_chip_check_config(struct aspeed_smc_chip *chip)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + u32 reg;
> +
> + reg = readl(controller->regs + CONFIG_REG);
> +
> + if (reg & aspeed_smc_chip_write_bit(chip))
> + return;
> +
> + dev_dbg(controller->dev, "config write is not set ! @%p: 0x%08x\n",
> + controller->regs + CONFIG_REG, reg);
> + reg |= aspeed_smc_chip_write_bit(chip);
> + writel(reg, controller->regs + CONFIG_REG);
> +}
> +
> +static void aspeed_smc_start_user(struct spi_nor *nor)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> + u32 ctl = chip->ctl_val[smc_base];
> +
> + /*
> + * When the chip is controlled in user mode, we need write
> + * access to send the opcodes to it. So check the config.
> + */
> + aspeed_smc_chip_check_config(chip);
> +
> + ctl |= CONTROL_COMMAND_MODE_USER |
> + CONTROL_CE_STOP_ACTIVE_CONTROL;
> + writel(ctl, chip->ctl);
> +
> + ctl &= ~CONTROL_CE_STOP_ACTIVE_CONTROL;
> + writel(ctl, chip->ctl);
> +}
> +
> +static void aspeed_smc_stop_user(struct spi_nor *nor)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + u32 ctl = chip->ctl_val[smc_read];
> + u32 ctl2 = ctl | CONTROL_COMMAND_MODE_USER |
> + CONTROL_CE_STOP_ACTIVE_CONTROL;
> +
> + writel(ctl2, chip->ctl); /* stop user CE control */
> + writel(ctl, chip->ctl); /* default to fread or read mode */
> +}
> +
This driver seems to use only the "USER" mode so why do you go back the
the "FREAD" or "READ" modes at the very end of aspeed_smc_stop_user() as
the comment suggests?
Do you plan to implement other modes later? Can't you just stay in
"USER" mode? I guess you just need the chip-select control part.
> +static int aspeed_smc_prep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_lock(&chip->controller->mutex);
> + return 0;
> +}
> +
> +static void aspeed_smc_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_unlock(&chip->controller->mutex);
> +}
> +
> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
> + aspeed_smc_read_from_ahb(buf, chip->ahb_base, len);
> + aspeed_smc_stop_user(nor);
> + return 0;
> +}
> +
> +static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> + int len)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
> + aspeed_smc_write_to_ahb(chip->ahb_base, buf, len);
> + aspeed_smc_stop_user(nor);
> + return 0;
> +}
> +
> +static void aspeed_smc_send_cmd_addr(struct spi_nor *nor, u8 cmd, u32 addr)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> + __be32 temp;
> + u32 cmdaddr;
> +
> + switch (nor->addr_width) {
> + default:
> + WARN_ONCE(1, "Unexpected address width %u, defaulting to 3\n",
> + nor->addr_width);
> + /* FALLTHROUGH */
> + case 3:
> + cmdaddr = addr & 0xFFFFFF;
> + cmdaddr |= cmd << 24;
> +
> + temp = cpu_to_be32(cmdaddr);
> + aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
> + break;
> + case 4:
> + temp = cpu_to_be32(addr);
> + aspeed_smc_write_to_ahb(chip->ahb_base, &cmd, 1);
> + aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
> + break;
> + }
> +}
> +
> +static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
> + size_t len, u_char *read_buf)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
Here, please check nor->read_dummy to write the relevant number dummy
bytes between the address and data cycles.
It should not need too much work to add support to the dummy clock
cycles and it's more reliable/safe.
Indeed, even if you call the current spi_nor_scan() function with the
enum read_mode SPI_NOR_NORMAL value, this function just doesn't care and
selects the Fast Read (0Bh) command instead of the Read (03h) command
for nor->read_opcode if the "m25p,fast-read" DT property is set.
So if any end user sets this property in a custom DT,
aspeed_smc_read_user() would just fail.
Hence I think it's worth dealing with dummy cycles now rather than later.
Actually all (Fast) Read commands but the legacy Read (03h) command need
dummy cycles. So the Read SFDP (5Ah) command does.
For all the (Q)SPI memories I've seen till now, the default factory
settings for the number of dummy cycles are chosen so it always
corresponds to entire bytes, whatever the SPI protocol is (SPI 1-1-2,
1-2-2, 1-1-4, 1-4-4, ...).
Besides, I recommend you use the 0xFF value for dummy cycles: this value
prevents the memory from entering its continuous mode by mistake.
The 0xFF value works for all manufacturers. The SFDP specification seems
to confirm that.
> + aspeed_smc_read_from_ahb(read_buf, chip->ahb_base, len);
> + aspeed_smc_stop_user(nor);
> + return len;
> +}
> +
> +static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to,
> + size_t len, const u_char *write_buf)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
> + aspeed_smc_write_to_ahb(chip->ahb_base, write_buf, len);
> + aspeed_smc_stop_user(nor);
> + return len;
> +}
> +
> +static int aspeed_smc_unregister(struct aspeed_smc_controller *controller)
> +{
> + struct aspeed_smc_chip *chip;
> + int n;
> +
> + for (n = 0; n < controller->info->nce; n++) {
> + chip = controller->chips[n];
> + if (chip)
> + mtd_device_unregister(&chip->nor.mtd);
> + }
> +
> + return 0;
> +}
> +
> +static int aspeed_smc_remove(struct platform_device *dev)
> +{
> + return aspeed_smc_unregister(platform_get_drvdata(dev));
> +}
> +
> +static const struct of_device_id aspeed_smc_matches[] = {
> + { .compatible = "aspeed,ast2500-fmc", .data = &fmc_2500_info },
> + { .compatible = "aspeed,ast2500-spi", .data = &spi_2500_info },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, aspeed_smc_matches);
> +
> +/*
> + * Each chip has a mapping window defined by a segment address
> + * register defining a start and an end address on the AHB bus. These
> + * addresses can be configured to fit the chip size and offer a
> + * contiguous memory region across chips. For the moment, we only
> + * check that each chip segment is valid.
> + */
> +static void __iomem *aspeed_smc_chip_base(struct aspeed_smc_chip *chip,
> + struct resource *res)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + u32 offset = 0;
> + u32 reg;
> +
> + if (controller->info->nce > 1) {
> + reg = readl(controller->regs + SEGMENT_ADDR_REG0 +
> + chip->cs * 4);
> +
> + if (SEGMENT_ADDR_START(reg) >= SEGMENT_ADDR_END(reg))
> + return NULL;
> +
> + offset = SEGMENT_ADDR_START(reg) - res->start;
> + }
> +
> + return controller->ahb_base + offset;
> +}
> +
> +static void aspeed_smc_chip_enable_write(struct aspeed_smc_chip *chip)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + u32 reg;
> +
> + reg = readl(controller->regs + CONFIG_REG);
> +
> + reg |= aspeed_smc_chip_write_bit(chip);
> + writel(reg, controller->regs + CONFIG_REG);
> +}
> +
> +static void aspeed_smc_chip_set_type(struct aspeed_smc_chip *chip, int type)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + u32 reg;
> +
> + chip->type = type;
> +
> + reg = readl(controller->regs + CONFIG_REG);
> + reg &= ~(3 << (chip->cs * 2));
> + reg |= chip->type << (chip->cs * 2);
> + writel(reg, controller->regs + CONFIG_REG);
> +}
> +
> +/*
> + * The AST2500 FMC flash controller should be strapped by hardware, or
> + * autodetected, but the AST2500 SPI flash needs to be set.
> + */
> +static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + u32 reg;
> +
> + if (chip->controller->info == &spi_2500_info) {
> + reg = readl(controller->regs + CE_CONTROL_REG);
> + reg |= 1 << chip->cs;
> + writel(reg, controller->regs + CE_CONTROL_REG);
> + }
> +}
> +
> +static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
> + struct resource *res)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + const struct aspeed_smc_info *info = controller->info;
> + u32 reg, base_reg;
> +
> + /*
> + * Always turn on the write enable bit to allow opcodes to be
> + * sent in user mode.
> + */
> + aspeed_smc_chip_enable_write(chip);
> +
> + /* The driver only supports SPI type flash */
> + if (info->hastype)
> + aspeed_smc_chip_set_type(chip, smc_type_spi);
> +
> + /*
> + * Configure chip base address in memory
> + */
> + chip->ahb_base = aspeed_smc_chip_base(chip, res);
> + if (!chip->ahb_base) {
> + dev_warn(chip->nor.dev, "CE segment window closed.\n");
> + return -EINVAL;
> + }
> +
> + /*
> + * Get value of the inherited control register. U-Boot usually
> + * does some timing calibration on the FMC chip, so it's good
> + * to keep them. In the future, we should handle calibration
> + * from Linux.
> + */
> + reg = readl(chip->ctl);
> + dev_dbg(controller->dev, "control register: %08x\n", reg);
> +
> + base_reg = reg & CONTROL_KEEP_MASK;
> + if (base_reg != reg) {
> + dev_info(controller->dev,
> + "control register changed to: %08x\n",
> + base_reg);
dev_dbg() should be enough: end users don't know what to do with the new
control register value, do they?
This is just a suggestion, you can keep dev_info() if you want, I don't
mind :)
> + }
> + chip->ctl_val[smc_base] = base_reg;
> +
> + /*
> + * Retain the prior value of the control register as the
> + * default if it was normal access mode. Otherwise start with
> + * the sanitized base value set to read mode.
> + */
> + if ((reg & CONTROL_COMMAND_MODE_MASK) ==
> + CONTROL_COMMAND_MODE_NORMAL)
> + chip->ctl_val[smc_read] = reg;
> + else
> + chip->ctl_val[smc_read] = chip->ctl_val[smc_base] |
> + CONTROL_COMMAND_MODE_NORMAL;
> +
> + dev_dbg(controller->dev, "default control register: %08x\n",
> + chip->ctl_val[smc_read]);
> + return 0;
> +}
> +
> +static int aspeed_smc_chip_setup_finish(struct aspeed_smc_chip *chip)
> +{
> + struct aspeed_smc_controller *controller = chip->controller;
> + const struct aspeed_smc_info *info = controller->info;
> + u32 cmd;
> +
> + if (chip->nor.addr_width == 4 && info->set_4b)
> + info->set_4b(chip);
> +
> + /*
> + * base mode has not been optimized yet. use it for writes.
> + */
> + chip->ctl_val[smc_write] = chip->ctl_val[smc_base] |
> + chip->nor.program_opcode << CONTROL_COMMAND_SHIFT |
> + CONTROL_COMMAND_MODE_WRITE;
> +
> + dev_dbg(controller->dev, "write control register: %08x\n",
> + chip->ctl_val[smc_write]);
> +
> + /*
> + * TODO: Adjust clocks if fast read is supported and interpret
> + * SPI-NOR flags to adjust controller settings.
> + */
> + switch (chip->nor.flash_read) {
> + case SPI_NOR_NORMAL:
> + cmd = CONTROL_COMMAND_MODE_NORMAL;
> + break;
> + case SPI_NOR_FAST:
> + cmd = CONTROL_COMMAND_MODE_FREAD;
> + break;
> + default:
> + dev_err(chip->nor.dev, "unsupported SPI read mode\n");
> + return -EINVAL;
> + }
> +
> + chip->ctl_val[smc_read] |= cmd |
> + CONTROL_IO_DUMMY_SET(chip->nor.read_dummy / 8);
> +
> + dev_dbg(controller->dev, "base control register: %08x\n",
> + chip->ctl_val[smc_read]);
> + return 0;
> +}
> +
Why do you configure both chip->ctrl_val[smc_write] and
chip->ctrl_val[smc_read] if the driver actually only uses
chip->ctrl_val[smc_base] ?
all aspeed_smc_[read|write]_[reg|user]() functions call
aspeed_smc_[start|stop]_user(), so this driver always selects the "USER"
mode and configures the control register based on chip->ctrl_val[smc_base].
> +static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
> + struct device_node *np, struct resource *r)
> +{
> + const struct aspeed_smc_info *info = controller->info;
> + struct device *dev = controller->dev;
> + struct device_node *child;
> + unsigned int cs;
> + int ret = -ENODEV;
> +
> + for_each_available_child_of_node(np, child) {
> + struct aspeed_smc_chip *chip;
> + struct spi_nor *nor;
> + struct mtd_info *mtd;
> +
> + /* This driver does not support NAND or NOR flash devices. */
> + if (!of_device_is_compatible(child, "jedec,spi-nor"))
> + continue;
> +
> + ret = of_property_read_u32(child, "reg", &cs);
> + if (ret) {
> + dev_err(dev, "Couldn't not read chip select.\n");
> + break;
> + }
> +
> + if (cs >= info->nce) {
> + dev_err(dev, "Chip select %d out of range.\n",
> + cs);
> + ret = -ERANGE;
> + break;
> + }
> +
> + if (controller->chips[cs]) {
> + dev_err(dev, "Chip select %d already in use by %s\n",
> + cs, dev_name(controller->chips[cs]->nor.dev));
> + ret = -EBUSY;
> + break;
> + }
> +
> + chip = devm_kzalloc(controller->dev, sizeof(*chip), GFP_KERNEL);
> + if (!chip) {
> + ret = -ENOMEM;
> + break;
> + }
> +
> + chip->controller = controller;
> + chip->ctl = controller->regs + info->ctl0 + cs * 4;
> + chip->cs = cs;
> +
> + nor = &chip->nor;
> + mtd = &nor->mtd;
> +
> + nor->dev = dev;
> + nor->priv = chip;
> + spi_nor_set_flash_node(nor, child);
> + nor->read = aspeed_smc_read_user;
> + nor->write = aspeed_smc_write_user;
> + nor->read_reg = aspeed_smc_read_reg;
> + nor->write_reg = aspeed_smc_write_reg;
> + nor->prepare = aspeed_smc_prep;
> + nor->unprepare = aspeed_smc_unprep;
> +
> + mtd->name = of_get_property(child, "label", NULL);
This new "label" DT property should be removed from this patch and send
in a dedicated patch to be discussed separately. However I agree with
Marek: it looks generic so maybe it could be managed directly from
mtd_device_register() since setting such as name could also be done when
using a NAND flash. Anyway, I don't see the link between this name and
spi-nor. Hence I don't think the DT property should be documented in
jedec,spi-nor.txt.
Be patient because I expect such a topic to be discussed quite a long
time before we all agree, even if this is "just" a new DT property ;)
Best regards,
Cyrille
> +
> + ret = aspeed_smc_chip_setup_init(chip, r);
> + if (ret)
> + break;
> +
> + /*
> + * TODO: Add support for SPI_NOR_QUAD and SPI_NOR_DUAL
> + * attach when board support is present as determined
> + * by of property.
> + */
> + ret = spi_nor_scan(nor, NULL, SPI_NOR_NORMAL);
> + if (ret)
> + break;
> +
> + ret = aspeed_smc_chip_setup_finish(chip);
> + if (ret)
> + break;
> +
> + ret = mtd_device_register(mtd, NULL, 0);
> + if (ret)
> + break;
> +
> + controller->chips[cs] = chip;
> + }
> +
> + if (ret)
> + aspeed_smc_unregister(controller);
> +
> + return ret;
> +}
> +
> +static int aspeed_smc_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device *dev = &pdev->dev;
> + struct aspeed_smc_controller *controller;
> + const struct of_device_id *match;
> + const struct aspeed_smc_info *info;
> + struct resource *res;
> + int ret;
> +
> + match = of_match_device(aspeed_smc_matches, &pdev->dev);
> + if (!match || !match->data)
> + return -ENODEV;
> + info = match->data;
> +
> + controller = devm_kzalloc(&pdev->dev, sizeof(*controller) +
> + info->nce * sizeof(controller->chips[0]), GFP_KERNEL);
> + if (!controller)
> + return -ENOMEM;
> + controller->info = info;
> + controller->dev = dev;
> +
> + mutex_init(&controller->mutex);
> + platform_set_drvdata(pdev, controller);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + controller->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(controller->regs)) {
> + dev_err(dev, "Cannot remap controller address.\n");
> + return PTR_ERR(controller->regs);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + controller->ahb_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(controller->ahb_base)) {
> + dev_err(dev, "Cannot remap controller address.\n");
> + return PTR_ERR(controller->ahb_base);
> + }
> +
> + ret = aspeed_smc_setup_flash(controller, np, res);
> + if (ret)
> + dev_err(dev, "Aspeed SMC probe failed %d\n", ret);
> +
> + return ret;
> +}
> +
> +static struct platform_driver aspeed_smc_driver = {
> + .probe = aspeed_smc_probe,
> + .remove = aspeed_smc_remove,
> + .driver = {
> + .name = DEVICE_NAME,
> + .of_match_table = aspeed_smc_matches,
> + }
> +};
> +
> +module_platform_driver(aspeed_smc_driver);
> +
> +MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
> +MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
> +MODULE_LICENSE("GPL v2");
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 0/3] clkdev: add devm_get_clk_from_child()
From: Kuninori Morimoto @ 2016-12-16 0:02 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Boyd, Russell King - ARM Linux, Rob Herring, Linux-ALSA,
Linux-DT, Michael Turquette, Linux-Kernel, linux-clk, Linux-ARM
In-Reply-To: <20161215122115.zpxawc2xdc45rczf@sirena.org.uk>
Hi Mark
> > Mark, I think I should re-post 2nd patch (3rd will be dropped) after
> > merge window ? There will be no branch dependency
>
> Should be fine without but obviously if it looks like it's gone AWOL
> then reposting would be good.
OK, Thanks !
^ permalink raw reply
* [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers
From: Stuart Yoder @ 2016-12-16 0:16 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stuart Yoder,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
is defined by the binding of a specific SMMU. The ARM SMMU binding
never explicitly uses the term 'specifier' at all. Update implicit
references to use the explicit term.
In the iommu-map binding change references to iommu-specifier to
"IOMMU specifier" so we are 100% consistent everywhere with terminology
and capitalization.
Signed-off-by: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +++++-----
Documentation/devicetree/bindings/pci/pci-iommu.txt | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index e862d148..6cdf32d 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -36,15 +36,15 @@ conditions.
combined interrupt, it must be listed multiple times.
- #iommu-cells : See Documentation/devicetree/bindings/iommu/iommu.txt
- for details. With a value of 1, each "iommus" entry
+ for details. With a value of 1, each IOMMU specifier
represents a distinct stream ID emitted by that device
into the relevant SMMU.
SMMUs with stream matching support and complex masters
- may use a value of 2, where the second cell represents
- an SMR mask to combine with the ID in the first cell.
- Care must be taken to ensure the set of matched IDs
- does not result in conflicts.
+ may use a value of 2, where the second cell of the
+ IOMMU specifier represents an SMR mask to combine with
+ the ID in the first cell. Care must be taken to ensure
+ the set of matched IDs does not result in conflicts.
** System MMU optional properties:
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
index 56c8296..0def586 100644
--- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
+++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
@@ -32,17 +32,17 @@ PCI root complex
Optional properties
-------------------
-- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
+- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
data.
The property is an arbitrary number of tuples of
(rid-base,iommu,iommu-base,length).
Any RID r in the interval [rid-base, rid-base + length) is associated with
- the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
+ the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
- iommu-map-mask: A mask to be applied to each Requester ID prior to being
- mapped to an iommu-specifier per the iommu-map property.
+ mapped to an IOMMU specifier per the iommu-map property.
Example (1)
--
1.9.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Doug Anderson @ 2016-12-16 0:52 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Mark Rutland, devicetree@vger.kernel.org, Thomas Abraham,
linux-pm@vger.kernel.org, Ben Gamari, Russell King, Rob Herring,
linux-kernel@vger.kernel.org, Javier Martinez Canillas,
Kukjin Kim, Krzysztof Kozlowski, Alim, Arjun K V, Andreas Faerber,
linux-samsung-soc, linux-arm-kernel@lists.infradead.org
In-Reply-To: <2340115.HEG9AYUCMD@amdc3058>
Hi,
On Wed, Dec 14, 2016 at 5:28 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>
> Hi,
>
>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>> > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>> > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>> > cooling maps to account for new OPPs.
>> >
>> > Since new OPPs are not available on all Exynos5422/5800 boards modify
>> > dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>> > Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>> >
>> > Tested on Odroid-XU3 and XU3 Lite.
>> >
>> > Cc: Doug Anderson <dianders@chromium.org>
>> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>> > Cc: Andreas Faerber <afaerber@suse.de>
>> > Cc: Thomas Abraham <thomas.ab@samsung.com>
>> > Cc: Ben Gamari <ben@smart-cactus.org>
>> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>> > ---
>> > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>> > arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>> > arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>> > arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>> > 4 files changed, 43 insertions(+), 7 deletions(-)
>> >
>> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>> > @@ -118,7 +118,7 @@
>> > /*
>> > * When reaching cpu_alert3, reduce CPU
>> > * by 2 steps. On Exynos5422/5800 that would
>> > - * be: 1600 MHz and 1100 MHz.
>> > + * (usually) be: 1800 MHz and 1200 MHz.
>> > */
>> > map3 {
>> > trip = <&cpu_alert3>;
>> > @@ -131,16 +131,16 @@
>> >
>> > /*
>> > * When reaching cpu_alert4, reduce CPU
>> > - * further, down to 600 MHz (11 steps for big,
>> > - * 7 steps for LITTLE).
>> > + * further, down to 600 MHz (13 steps for big,
>> > + * 8 steps for LITTLE).
>> > */
>> > - map5 {
>> > + cooling_map5: map5 {
>> > trip = <&cpu_alert4>;
>> > - cooling-device = <&cpu0 3 7>;
>> > + cooling-device = <&cpu0 3 8>;
>> > };
>> > - map6 {
>> > + cooling_map6: map6 {
>> > trip = <&cpu_alert4>;
>> > - cooling-device = <&cpu4 3 11>;
>> > + cooling-device = <&cpu4 3 13>;
>> > };
>> > };
>> > };
>> > Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>> > @@ -21,6 +21,23 @@
>> > compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>> > };
>> >
>> > +&cluster_a15_opp_table {
>> > + /delete-node/opp@2000000000;
>> > + /delete-node/opp@1900000000;
>> > +};
>> > +
>> > +&cluster_a7_opp_table {
>> > + /delete-node/opp@1400000000;
>> > +};
>> > +
>>
>> I think that a comment in the DTS why these operating points aren't available
>> in this board will make more clear why the nodes are being deleted.
>
> Ok, I will add these comments in the next patch revision.
>
>> > +&cooling_map5 {
>> > + cooling-device = <&cpu0 3 7>;
>> > +};
>> > +
>> > +&cooling_map6 {
>> > + cooling-device = <&cpu4 3 11>;
>> > +};
>> > +
>> > &pwm {
>> > /*
>> > * PWM 0 -- fan
>> > Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>> > @@ -146,6 +146,10 @@
>> > vdd-supply = <&ldo9_reg>;
>> > };
>> >
>> > +&cluster_a7_opp_table {
>> > + /delete-property/opp@1400000000;
>> > +};
>> > +
>> > &cpu0 {
>> > cpu-supply = <&buck2_reg>;
>> > };
>> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>> > @@ -24,6 +24,16 @@
>> > };
>> >
>> > &cluster_a15_opp_table {
>> > + opp@2000000000 {
>> > + opp-hz = /bits/ 64 <2000000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>> > + opp@1900000000 {
>> > + opp-hz = /bits/ 64 <1900000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>> > opp@1700000000 {
>> > opp-microvolt = <1250000>;
>> > };
>> > @@ -85,6 +95,11 @@
>> > };
>> >
>>
>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>> INT rail would need to be scaled up as well since there's a maximum voltage
>> difference between the ARM and INT rails before the system becomes unstable:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>> https://lkml.org/lkml/2014/5/2/419
>>
>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>> the maximum voltage skew is between a limit. But that never made to mainline:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>> https://lkml.org/lkml/2014/4/29/28
>>
>> Did that change and there's infrastructure in mainline now to cope with that?
>> If that's the case, I think it would be good to mention in the commit message.
>
> I was not aware of this limitation and AFAIK mainline has currently
> no code to handle it. I also cannot find any code to handle this in
> Hardkernel's vendor kernel for Odroid-XU3 board.
>
> Do you know whether this problem exists also on Exynos5422/5800
> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> regulator code also on Exynos5800 SoC based Peach Pi board but was
> the problem actually present on this board?
This was a long time ago and my memory is quite fuzzy. ...and I think
others have answered some of this already...
...but from my memory:
* This problem was said to exist on all Exynos 5420/5422/5800 SoCs.
* Samsung's original proposal included using the QoS subsystem to
enforce these constraints. I don't know where the Hardkernel source
is offhand, but you could check if that solution was used there? I
see one comment that links to these CLs:
https://chromium-review.googlesource.com/#/c/187420/
https://chromium-review.googlesource.com/#/c/187231/2
https://chromium-review.googlesource.com/#/c/184439/7
https://chromium-review.googlesource.com/#/c/184460/10
https://chromium-review.googlesource.com/#/c/186804/4
https://chromium-review.googlesource.com/#/c/186805/4
https://chromium-review.googlesource.com/#/c/186806/3
https://chromium-review.googlesource.com/#/c/186353/6
* Before using the voltage locker, we used an interrim solution of
bumping the INT frequency up to 500 MHz. See
<https://chromium-review.googlesource.com/#/c/187992/> and
<https://chromium-review.googlesource.com/#/c/187888/>. Perhaps this
is something that's happening upstream?
> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> (unfortunately Inderpal's email is no longer working). ]
>
> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> IOW if the problem exists it is already present in the mainline
> kernel.
Interesting. In the ChromeOS tree I see significantly higher voltages
needed... Note that one might naively look at
<https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
1362500, /* L0 2100 */
1312500, /* L1 2000 */
..but, amazingly enough those voltages aren't used at all. Surprise!
I believe that the above numbers are actually not used and the ASV
numbers are used instead. See
<https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
{ 2100000,
1350000, 1350000, 1350000, 1350000, 1350000,
1337500, 1325000, 1312500, 1300000, 1287500,
1275000, 1262500, 1250000, 1237500 },
I believe that interpretation there is: some bins of the CPU can run
at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
running on a CPU from a nice bin?
---
Anyway, I'm not setup at the moment to do a whole lot on exynos boards
(I'd have to go and dig some out and set them up again), so not sure
I'll be terribly useful in this discussion. ...but I can try to dig
up history, anyway.
-Doug
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Doug Anderson @ 2016-12-16 0:54 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Mark Rutland, devicetree@vger.kernel.org, Thomas Abraham,
linux-pm@vger.kernel.org, Ben Gamari, Russell King, Rob Herring,
linux-kernel@vger.kernel.org, Javier Martinez Canillas,
Kukjin Kim, Krzysztof Kozlowski, Arjun K V, Andreas Faerber,
linux-samsung-soc, linux-arm-kernel@lists.infradead.org
In-Reply-To: <10512254.nyUcL0zgTP@amdc3058>
Hi,
On Thu, Dec 15, 2016 at 3:55 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> cooling maps to account for new OPPs.
>
> Since new OPPs are not available on all Exynos5422/5800 boards modify
> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>
> Tested on Odroid-XU3 and XU3 Lite.
>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Cc: Arjun K V <arjun.kv@samsung.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> v2:
> - added comments about limitations of SoC revisions used by Odroid-XU3 Lite and
> Peach Pi boards (suggested by Javier)
> - removed redundant opp_a7_14 label
> - added Arjun to Cc:
>
> Javier, could you test it on Peach Pi board?
>
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 ++++++-------
> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 22 +++++++++++++++++++++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 9 ++++++++
> arch/arm/boot/dts/exynos5800.dtsi | 15 ++++++++++++++
> 4 files changed, 53 insertions(+), 7 deletions(-)
>
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-15 12:43:54.361955949 +0100
> @@ -118,7 +118,7 @@
> /*
> * When reaching cpu_alert3, reduce CPU
> * by 2 steps. On Exynos5422/5800 that would
> - * be: 1600 MHz and 1100 MHz.
> + * (usually) be: 1800 MHz and 1200 MHz.
> */
> map3 {
> trip = <&cpu_alert3>;
> @@ -131,16 +131,16 @@
>
> /*
> * When reaching cpu_alert4, reduce CPU
> - * further, down to 600 MHz (11 steps for big,
> - * 7 steps for LITTLE).
> + * further, down to 600 MHz (13 steps for big,
> + * 8 steps for LITTLE).
> */
> - map5 {
> + cooling_map5: map5 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu0 3 7>;
> + cooling-device = <&cpu0 3 8>;
> };
> - map6 {
> + cooling_map6: map6 {
> trip = <&cpu_alert4>;
> - cooling-device = <&cpu4 3 11>;
> + cooling-device = <&cpu4 3 13>;
> };
> };
> };
> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-15 12:43:54.361955949 +0100
> @@ -21,6 +21,28 @@
> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> };
>
> +/*
> + * Odroid XU3-Lite board uses SoC revision with lower maximum frequencies
> + * than Odroid XU3/XU4 boards: 1.8 GHz for A15 cores & 1.3 GHz for A7 cores.
> + * Therefore we need to update OPPs tables and thermal maps accordingly.
> + */
> +&cluster_a15_opp_table {
> + /delete-node/opp@2000000000;
> + /delete-node/opp@1900000000;
> +};
> +
> +&cluster_a7_opp_table {
> + /delete-node/opp@1400000000;
> +};
> +
> +&cooling_map5 {
> + cooling-device = <&cpu0 3 7>;
> +};
> +
> +&cooling_map6 {
> + cooling-device = <&cpu4 3 11>;
> +};
> +
> &pwm {
> /*
> * PWM 0 -- fan
> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-15 12:43:54.361955949 +0100
> @@ -146,6 +146,15 @@
> vdd-supply = <&ldo9_reg>;
> };
>
> +/*
> + * Peach Pi board uses SoC revision with lower maximum frequency for A7 cores
> + * (1.3 GHz instead of 1.4 GHz) than Odroid XU3/XU4 boards. Thus we need to
> + * update A7 OPPs table accordingly.
> + */
> +&cluster_a7_opp_table {
> + /delete-property/opp@1400000000;
> +};
> +
> &cpu0 {
> cpu-supply = <&buck2_reg>;
> };
> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> ===================================================================
> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> @@ -24,6 +24,16 @@
> };
>
> &cluster_a15_opp_table {
> + opp@2000000000 {
> + opp-hz = /bits/ 64 <2000000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
> + opp@1900000000 {
> + opp-hz = /bits/ 64 <1900000000>;
> + opp-microvolt = <1250000>;
> + clock-latency-ns = <140000>;
> + };
I don't think the voltages you listed are high enough for all peach pi
boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
I did. See my response to v1.
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Mark Greer @ 2016-12-16 1:06 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
justin-R+k406RtEhcAvxtiuMwx3w
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Geoff.
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
Please add an informative commit description to all of your commits.
No matter how trivial this patch may seem to you now, it may not be
to others (or to you in a few years).
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 26c9dbb..2d2a077 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1181,27 +1180,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
> switch (tech) {
> case NFC_DIGITAL_RF_TECH_106A:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
nit: s/0xF8/0xf8/ please (for consistency with the rest of the file.).
Otherwise, it looks good.
Thanks,
Mark
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Mark Greer @ 2016-12-16 1:13 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
justin-R+k406RtEhcAvxtiuMwx3w
In-Reply-To: <1481841044-4314-2-git-send-email-glansberry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
Missing commit description.
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 2d2a077..b4c37ab 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1048,6 +1049,11 @@ static int trf7970a_init(struct trf7970a *trf)
> if (ret)
> goto err_out;
>
> + ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
> + trf->io_ctrl|TRF7970A_REG_IO_CTRL_VRS(0x1));
s/l|T/l | T/
Otherwise, looks good.
Mark
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-16 1:18 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
justin-R+k406RtEhcAvxtiuMwx3w, Jaret Cantu
In-Reply-To: <1481841044-4314-3-git-send-email-glansberry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the curent state of the trf7970a is reading but
> a request has been made to send a command.
>
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
Maybe its just me but I find this description a little hard to grok.
Mind reworking it?
The patch itself looks fine.
Thanks,
Mark
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RFC: extend iommu-map binding to support #iommu-cells > 1
From: Stuart Yoder @ 2016-12-16 2:36 UTC (permalink / raw)
To: Mark Rutland, robin.murphy-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
For context, please see the thread:
https://www.spinics.net/lists/arm-kernel/msg539066.html
The existing iommu-map binding did not account for the situation where
#iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
of the IOMMU specifier being the SMR mask. The existing binding defines
the mapping as:
Any RID r in the interval [rid-base, rid-base + length) is associated with
the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
...and that does not work if iommu-base is 2 cells, the second being the
SMR mask.
While this can be worked around by always having length=1, it seems we
can get this cleaned up by updating the binding definition for iommu-map.
See patch below. Thoughts?
Thanks,
Stuart
-------------------------------------------------------------------------
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
index 56c8296..e81b461 100644
--- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
+++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
@@ -38,8 +38,20 @@ Optional properties
The property is an arbitrary number of tuples of
(rid-base,iommu,iommu-base,length).
- Any RID r in the interval [rid-base, rid-base + length) is associated with
- the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
+ If the associated IOMMU has an #iommu-cells value of 1, any RID r in the
+ interval [rid-base, rid-base + length) is associated with the listed IOMMU,
+ with the iommu-specifier (r - rid-base + iommu-base).
+
+ ARM SMMU Note:
+ The ARM SMMU binding permits an #iommu-cells value of 2 and in this
+ case defines an IOMMU specifier to be: (stream-id,smr-mask)
+
+ In an iommu-map this means the iommu-base consists of 2 cells:
+ (rid-base,iommu,[stream-id,smr-mask],length).
+
+ In this case the RID to IOMMU specifier mapping is defined to be:
+ any RID r in the interval [rid-base, rid-base + length) is associated
+ with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-id).
- iommu-map-mask: A mask to be applied to each Requester ID prior to being
mapped to an iommu-specifier per the iommu-map property.
^ permalink raw reply related
* RE: RFC: extend iommu-map binding to support #iommu-cells > 1
From: Bharat Bhushan @ 2016-12-16 3:46 UTC (permalink / raw)
To: Stuart Yoder, Mark Rutland,
robin.murphy-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <VI1PR0401MB2638DE2D30F8423F6F8C7A6E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
> -----Original Message-----
> From: Stuart Yoder
> Sent: Friday, December 16, 2016 8:07 AM
> To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> will.deacon-5wv7dgnIgG8@public.gmane.org
> Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Bharat Bhushan <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>;
> Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; Diana Madalina Craciun
> <diana.craciun-3arQi8VN3Tc@public.gmane.org>; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org
> Subject: RFC: extend iommu-map binding to support #iommu-cells > 1
>
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell of
> the IOMMU specifier being the SMR mask. The existing binding defines the
> mapping as:
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
>
> ...and that does not work if iommu-base is 2 cells, the second being the SMR
> mask.
>
> While this can be worked around by always having length=1, it seems we can
> get this cleaned up by updating the binding definition for iommu-map.
>
> See patch below. Thoughts?
>
> Thanks,
> Stuart
>
> -------------------------------------------------------------------------
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..e81b461 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -38,8 +38,20 @@ Optional properties
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> - Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + If the associated IOMMU has an #iommu-cells value of 1, any RID r in
> + the interval [rid-base, rid-base + length) is associated with the
> + listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> +
> + ARM SMMU Note:
> + The ARM SMMU binding permits an #iommu-cells value of 2 and in this
> + case defines an IOMMU specifier to be: (stream-id,smr-mask)
> +
> + In an iommu-map this means the iommu-base consists of 2 cells:
> + (rid-base,iommu,[stream-id,smr-mask],length).
> +
> + In this case the RID to IOMMU specifier mapping is defined to be:
> + any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-
> id).
Should not this be (r - rid-base + (stream-id & smr-mask)) ?
So basically stream-id ranges from (stream-id & smr-mask) - (stream-id & smr-mask + (length - 1) )
Thanks
-Bharat
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to
> being
> mapped to an iommu-specifier per the iommu-map property.
>
>
^ 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