2018-05-23 11:46:06

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

The PMIC_DA9063 is a complete misnomer, it denotes the value of the
DA9063 chip ID register, so rename it as such. It is also the value
of chip ID register of DA9063L though, so drop the enum as all the
DA9063 "models" share the same chip ID and thus the distinction will
have to be made using DT or otherwise.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
drivers/mfd/da9063-core.c | 2 +-
drivers/mfd/da9063-i2c.c | 2 +-
drivers/regulator/da9063-regulator.c | 2 +-
include/linux/mfd/da9063/core.h | 4 +---
4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 6c2870d4e754..00b3caee4e21 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
dev_err(da9063->dev, "Cannot read chip model id.\n");
return -EIO;
}
- if (model != PMIC_DA9063) {
+ if (model != PMIC_CHIP_ID_DA9063) {
dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
return -ENODEV;
}
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 981805a2c521..7f84030c8d53 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
}

static const struct i2c_device_id da9063_i2c_id[] = {
- {"da9063", PMIC_DA9063},
+ { "da9063", PMIC_CHIP_ID_DA9063 },
{},
};
MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 6a8f9cd69f52..87c884ae0064 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
{
.regulator_info = da9063_regulator_info,
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
- .dev_model = PMIC_DA9063,
+ .dev_model = PMIC_CHIP_ID_DA9063,
},
{ }
};
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index f3ae65db4c86..664f650d0086 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -29,9 +29,7 @@
#define DA9063_DRVNAME_RTC "da9063-rtc"
#define DA9063_DRVNAME_VIBRATION "da9063-vibration"

-enum da9063_models {
- PMIC_DA9063 = 0x61,
-};
+#define PMIC_CHIP_ID_DA9063 0x61

enum da9063_variant_codes {
PMIC_DA9063_AD = 0x3,
--
2.16.2



2018-05-23 11:43:48

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 2/6] mfd: da9063: Replace model with type

The model number stored in the struct da9063 is the same for all
variants of the da9063 since it is the chip ID, which is always
the same. Replace that with a separate identifier instead, which
allows us to discern the DA9063 variants by setting the type
based on either DT match or otherwise.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
drivers/mfd/da9063-core.c | 1 -
drivers/mfd/da9063-i2c.c | 5 +++--
drivers/regulator/da9063-regulator.c | 6 +++---
include/linux/mfd/da9063/core.h | 6 +++++-
4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 00b3caee4e21..7360b76b4f72 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -215,7 +215,6 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
return -ENODEV;
}

- da9063->model = model;
da9063->variant_code = variant_code;

ret = da9063_irq_init(da9063);
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 7f84030c8d53..5544ce8e3363 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -236,7 +236,7 @@ static const struct of_device_id da9063_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, da9063_dt_ids);
static int da9063_i2c_probe(struct i2c_client *i2c,
- const struct i2c_device_id *id)
+ const struct i2c_device_id *id)
{
struct da9063 *da9063;
int ret;
@@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, da9063);
da9063->dev = &i2c->dev;
da9063->chip_irq = i2c->irq;
+ da9063->type = (enum da9063_type)id->driver_data;

if (da9063->variant_code == PMIC_DA9063_AD) {
da9063_regmap_config.rd_table = &da9063_ad_readable_table;
@@ -280,7 +281,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
}

static const struct i2c_device_id da9063_i2c_id[] = {
- { "da9063", PMIC_CHIP_ID_DA9063 },
+ { "da9063", PMIC_TYPE_DA9063 },
{},
};
MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 87c884ae0064..9b5c28392ae6 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -98,7 +98,7 @@ struct da9063_regulator_info {
struct da9063_dev_model {
const struct da9063_regulator_info *regulator_info;
unsigned n_regulators;
- unsigned dev_model;
+ enum da9063_type type;
};

/* Single regulator settings */
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
{
.regulator_info = da9063_regulator_info,
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
- .dev_model = PMIC_CHIP_ID_DA9063,
+ .type = PMIC_TYPE_DA9063,
},
{ }
};
@@ -741,7 +741,7 @@ static int da9063_regulator_probe(struct platform_device *pdev)

/* Find regulators set for particular device model */
for (model = regulators_models; model->regulator_info; model++) {
- if (model->dev_model == da9063->model)
+ if (model->dev_model == da9063->type)
break;
}
if (!model->regulator_info) {
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index 664f650d0086..eb234582dcb2 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -31,6 +31,10 @@

#define PMIC_CHIP_ID_DA9063 0x61

+enum da9063_type {
+ PMIC_TYPE_DA9063 = 0,
+};
+
enum da9063_variant_codes {
PMIC_DA9063_AD = 0x3,
PMIC_DA9063_BB = 0x5,
@@ -76,7 +80,7 @@ enum da9063_irqs {
struct da9063 {
/* Device */
struct device *dev;
- unsigned short model;
+ enum da9063_type type;
unsigned char variant_code;
unsigned int flags;

--
2.16.2


2018-05-23 11:43:51

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 3/6] mfd: da9063: Add DA9063L type

Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
include/linux/mfd/da9063/core.h | 1 +
1 file changed, 1 insertion(+)

diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index eb234582dcb2..c3e917dd1860 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -33,6 +33,7 @@

enum da9063_type {
PMIC_TYPE_DA9063 = 0,
+ PMIC_TYPE_DA9063L,
};

enum da9063_variant_codes {
--
2.16.2


2018-05-23 11:44:09

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

The DA9063L does not contain RTC block, unlike the full DA9063.
Do not allow binding RTC driver on this variant of the chip.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
drivers/mfd/da9063-core.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 7360b76b4f72..263c83006413 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
.of_compatible = "dlg,da9063-onkey",
},
{
+ .name = DA9063_DRVNAME_VIBRATION,
+ },
+ { /* Only present on DA9063 , not on DA9063L */
.name = DA9063_DRVNAME_RTC,
.num_resources = ARRAY_SIZE(da9063_rtc_resources),
.resources = da9063_rtc_resources,
.of_compatible = "dlg,da9063-rtc",
},
- {
- .name = DA9063_DRVNAME_VIBRATION,
- },
};

static int da9063_clear_fault_log(struct da9063 *da9063)
@@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
{
struct da9063_pdata *pdata = da9063->dev->platform_data;
int model, variant_id, variant_code;
- int ret;
+ int da9063_devs_len, ret;

ret = da9063_clear_fault_log(da9063);
if (ret < 0)
@@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)

da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);

- ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
- ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
- NULL);
+ da9063_devs_len = ARRAY_SIZE(da9063_devs);
+ /* RTC, the last device in the list, is only present on DA9063 */
+ if (da9063->type == PMIC_TYPE_DA9063L)
+ da9063_devs_len -= 1;
+
+ ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
+ NULL, da9063->irq_base, NULL);
if (ret)
dev_err(da9063->dev, "Cannot add MFD cells\n");

--
2.16.2


2018-05-23 11:44:23

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support

Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
drivers/mfd/da9063-i2c.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 5544ce8e3363..84bbd2bbcd2a 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {

static const struct of_device_id da9063_dt_ids[] = {
{ .compatible = "dlg,da9063", },
+ { .compatible = "dlg,da9063l", },
{ }
};
MODULE_DEVICE_TABLE(of, da9063_dt_ids);
@@ -282,6 +283,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)

static const struct i2c_device_id da9063_i2c_id[] = {
{ "da9063", PMIC_TYPE_DA9063 },
+ { "da9063l", PMIC_TYPE_DA9063L },
{},
};
MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
--
2.16.2


2018-05-23 11:46:06

by Marek Vasut

[permalink] [raw]
Subject: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.

Signed-off-by: Marek Vasut <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Steve Twiss <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
---
drivers/regulator/da9063-regulator.c | 76 +++++++++++++++++++++---------------
1 file changed, 45 insertions(+), 31 deletions(-)

diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 9b5c28392ae6..92569bed24b9 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -529,6 +529,32 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
.ilimit = BFIELD(DA9063_REG_BUCK_ILIM_A,
DA9063_BMEM_ILIM_MASK),
},
+ {
+ DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
+ .suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
+ .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
+ },
+ {
+ DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
+ .suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
+ .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
+ },
+ {
+ DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
+ .suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
+ .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
+ },
+ {
+ DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
+ .suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
+ },
+ {
+ DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
+ .suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
+ .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
+ },
+
+ /* The following LDOs are present only on DA9063, not on DA9063L */
{
DA9063_LDO(DA9063, LDO1, 600, 20, 1860),
.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO1_SEL),
@@ -537,11 +563,6 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
DA9063_LDO(DA9063, LDO2, 600, 20, 1860),
.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO2_SEL),
},
- {
- DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
- .suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
- .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
- },
{
DA9063_LDO(DA9063, LDO4, 900, 20, 3440),
.suspend = BFIELD(DA9063_REG_DVC_2, DA9063_VLDO4_SEL),
@@ -555,29 +576,11 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
DA9063_LDO(DA9063, LDO6, 900, 50, 3600),
.suspend = BFIELD(DA9063_REG_LDO6_CONT, DA9063_VLDO6_SEL),
},
- {
- DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
- .suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
- .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
- },
- {
- DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
- .suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
- .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
- },
- {
- DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
- .suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
- },
+
{
DA9063_LDO(DA9063, LDO10, 900, 50, 3600),
.suspend = BFIELD(DA9063_REG_LDO10_CONT, DA9063_VLDO10_SEL),
},
- {
- DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
- .suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
- .oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
- },
};

/* Link chip model with regulators info table */
@@ -587,6 +590,11 @@ static struct da9063_dev_model regulators_models[] = {
.n_regulators = ARRAY_SIZE(da9063_regulator_info),
.type = PMIC_TYPE_DA9063,
},
+ {
+ .regulator_info = da9063_regulator_info,
+ .n_regulators = ARRAY_SIZE(da9063_regulator_info) - 6,
+ .type = PMIC_TYPE_DA9063L,
+ },
{ }
};

@@ -641,28 +649,34 @@ static struct of_regulator_match da9063_matches[] = {
[DA9063_ID_BPERI] = { .name = "bperi", },
[DA9063_ID_BCORES_MERGED] = { .name = "bcores-merged" },
[DA9063_ID_BMEM_BIO_MERGED] = { .name = "bmem-bio-merged", },
+ [DA9063_ID_LDO3] = { .name = "ldo3", },
+ [DA9063_ID_LDO7] = { .name = "ldo7", },
+ [DA9063_ID_LDO8] = { .name = "ldo8", },
+ [DA9063_ID_LDO9] = { .name = "ldo9", },
+ [DA9063_ID_LDO11] = { .name = "ldo11", },
+ /* The following LDOs are present only on DA9063, not on DA9063L */
[DA9063_ID_LDO1] = { .name = "ldo1", },
[DA9063_ID_LDO2] = { .name = "ldo2", },
- [DA9063_ID_LDO3] = { .name = "ldo3", },
[DA9063_ID_LDO4] = { .name = "ldo4", },
[DA9063_ID_LDO5] = { .name = "ldo5", },
[DA9063_ID_LDO6] = { .name = "ldo6", },
- [DA9063_ID_LDO7] = { .name = "ldo7", },
- [DA9063_ID_LDO8] = { .name = "ldo8", },
- [DA9063_ID_LDO9] = { .name = "ldo9", },
[DA9063_ID_LDO10] = { .name = "ldo10", },
- [DA9063_ID_LDO11] = { .name = "ldo11", },
};

static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
struct platform_device *pdev,
struct of_regulator_match **da9063_reg_matches)
{
+ struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
struct da9063_regulators_pdata *pdata;
struct da9063_regulator_data *rdata;
struct device_node *node;
+ int da9063_matches_len = ARRAY_SIZE(da9063_matches);
int i, n, num;

+ if (da9063->type == PMIC_TYPE_DA9063L)
+ da9063_matches_len -= 6;
+
node = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
if (!node) {
dev_err(&pdev->dev, "Regulators device node not found\n");
@@ -670,7 +684,7 @@ static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
}

num = of_regulator_match(&pdev->dev, node, da9063_matches,
- ARRAY_SIZE(da9063_matches));
+ da9063_matches_len);
of_node_put(node);
if (num < 0) {
dev_err(&pdev->dev, "Failed to match regulators\n");
@@ -689,7 +703,7 @@ static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
pdata->n_regulators = num;

n = 0;
- for (i = 0; i < ARRAY_SIZE(da9063_matches); i++) {
+ for (i = 0; i < da9063_matches_len; i++) {
if (!da9063_matches[i].init_data)
continue;

--
2.16.2


2018-05-23 11:50:34

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

On Wed, May 23, 2018 at 01:42:25PM +0200, Marek Vasut wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the

Acked-by: Mark Brown <[email protected]>


Attachments:
(No filename) (319.00 B)
signature.asc (499.00 B)
Download all attachments

2018-05-23 11:51:13

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

On Wed, May 23, 2018 at 01:42:26PM +0200, Marek Vasut wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which

Acked-by: Mark Brown <[email protected]>


Attachments:
(No filename) (310.00 B)
signature.asc (499.00 B)
Download all attachments

2018-05-23 11:52:33

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

On Wed, May 23, 2018 at 01:42:29PM +0200, Marek Vasut wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.

Acked-by: Mark Brown <[email protected]>


Attachments:
(No filename) (279.00 B)
signature.asc (499.00 B)
Download all attachments

2018-05-23 11:52:57

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On Wed, May 23, 2018 at 01:42:30PM +0200, Marek Vasut wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.

Acked-by: Mark Brown <[email protected]>


Attachments:
(No filename) (217.00 B)
signature.asc (499.00 B)
Download all attachments

2018-05-23 11:55:21

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will
> have to be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 11:57:29

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which
> allows us to discern the DA9063 variants by setting the type
> based on either DT match or otherwise.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
> i2c_set_clientdata(i2c, da9063);
> da9063->dev = &i2c->dev;
> da9063->chip_irq = i2c->irq;
> + da9063->type = (enum da9063_type)id->driver_data;

Nit: I think this cast (from unsigned long) is not needed.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 12:00:52

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 3/6] mfd: da9063: Add DA9063L type

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> Add type for DA9063L, which is a reduced variant of the DA9063
> without RTC block and with less regulators.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 12:03:23

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 12:06:06

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 12:06:57

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.
>
> Signed-off-by: Marek Vasut <[email protected]>

Reviewed-by: Geert Uytterhoeven <[email protected]>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2018-05-23 12:22:42

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

On 05/23/2018 01:55 PM, Geert Uytterhoeven wrote:
> On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <[email protected]> wrote:
>> The model number stored in the struct da9063 is the same for all
>> variants of the da9063 since it is the chip ID, which is always
>> the same. Replace that with a separate identifier instead, which
>> allows us to discern the DA9063 variants by setting the type
>> based on either DT match or otherwise.
>>
>> Signed-off-by: Marek Vasut <[email protected]>
>
> Reviewed-by: Geert Uytterhoeven <[email protected]>
>
>> --- a/drivers/mfd/da9063-i2c.c
>> +++ b/drivers/mfd/da9063-i2c.c
>> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>> i2c_set_clientdata(i2c, da9063);
>> da9063->dev = &i2c->dev;
>> da9063->chip_irq = i2c->irq;
>> + da9063->type = (enum da9063_type)id->driver_data;
>
> Nit: I think this cast (from unsigned long) is not needed.

Dropped

--
Best regards,
Marek Vasut

2018-05-24 11:51:06

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

Thanks Marek,

> On 23 May 2018 12:43 Marek Vasut wrote,
>
> To: [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>;
> Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>;
> Wolfram Sang <[email protected]>; [email protected]
> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>

There's potentially more to this file. Without an RTC the regmap access tables would change and the
usual DA9063 (BB silicon) tables would become invalid.
The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
would need to be updated for DA9063L, if a new chip model was needed.

The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.

static const struct regmap_range da9063l_bb_readable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_MON_A10_RES,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_ID_32_31,
}, {
.range_min = DA9063_REG_SEQ_A,
.range_max = DA9063_REG_AUTO3_LOW,
}, {
.range_min = DA9063_REG_T_OFFSET,
.range_max = DA9063_BB_REG_GP_ID_19,
}, {
.range_min = DA9063_REG_CHIP_ID,
.range_max = DA9063_REG_CHIP_VARIANT,
},
};

static const struct regmap_range da9063l_bb_writeable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_PAGE_CON,
}, {
.range_min = DA9063_REG_FAULT_LOG,
.range_max = DA9063_REG_VSYS_MON,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_ID_32_31,
}, {
.range_min = DA9063_REG_SEQ_A,
.range_max = DA9063_REG_AUTO3_LOW,
}, {
.range_min = DA9063_REG_CONFIG_I,
.range_max = DA9063_BB_REG_MON_REG_4,
}, {
.range_min = DA9063_BB_REG_GP_ID_0,
.range_max = DA9063_BB_REG_GP_ID_19,
},
};

static const struct regmap_range da9063l_bb_volatile_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_EVENT_D,
}, {
.range_min = DA9063_REG_CONTROL_A,
.range_max = DA9063_REG_CONTROL_B,
}, {
.range_min = DA9063_REG_CONTROL_E,
.range_max = DA9063_REG_CONTROL_F,
}, {
.range_min = DA9063_REG_BCORE2_CONT,
.range_max = DA9063_REG_LDO11_CONT,
}, {
.range_min = DA9063_REG_DVC_1,
.range_max = DA9063_REG_ADC_MAN,
}, {
.range_min = DA9063_REG_ADC_RES_L,
.range_max = DA9063_REG_MON_A10_RES,
}, {
.range_min = DA9063_REG_SEQ,
.range_max = DA9063_REG_SEQ,
}, {
.range_min = DA9063_REG_EN_32K,
.range_max = DA9063_REG_EN_32K,
}, {
.range_min = DA9063_BB_REG_MON_REG_5,
.range_max = DA9063_BB_REG_MON_REG_6,
},
};

However this is a larger and more wide-ranging change compared to the one proposed by Marek,
and would require other alterations to fit this in. Also I'm undecided to what it would really add
apart from a new chip model: I have been told accessing the DA9063 RTC register locations has
no effect in the DA9063L.

If the maintainers are happy with this, and if a chip model addition is really needed in future
it can be added later if required.

Acked-by: Steve Twiss <[email protected]>

Regards,
Steve

> Signed-off-by: Marek Vasut <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Lee Jones <[email protected]>
> Cc: Mark Brown <[email protected]>
> Cc: Steve Twiss <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> ---
> drivers/mfd/da9063-i2c.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index 5544ce8e3363..84bbd2bbcd2a 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {
>
> static const struct of_device_id da9063_dt_ids[] = {
> { .compatible = "dlg,da9063", },
> + { .compatible = "dlg,da9063l", },
> { }
> };
> MODULE_DEVICE_TABLE(of, da9063_dt_ids); @@ -282,6 +283,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
>
> static const struct i2c_device_id da9063_i2c_id[] = {
> { "da9063", PMIC_TYPE_DA9063 },
> + { "da9063l", PMIC_TYPE_DA9063L },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
> --
> 2.16.2


2018-05-24 12:05:39

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

Hi Marek,

On 23 May 2018 12:42 Marek Vasut wrote:

> To: [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> Subject: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
>
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value of chip ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will have to be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Lee Jones <[email protected]>
> Cc: Mark Brown <[email protected]>
> Cc: Steve Twiss <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> ---
> drivers/mfd/da9063-core.c | 2 +-
> drivers/mfd/da9063-i2c.c | 2 +-
> drivers/regulator/da9063-regulator.c | 2 +-
> include/linux/mfd/da9063/core.h | 4 +---
> 4 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 6c2870d4e754..00b3caee4e21 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
> dev_err(da9063->dev, "Cannot read chip model id.\n");
> return -EIO;
> }
> - if (model != PMIC_DA9063) {
> + if (model != PMIC_CHIP_ID_DA9063) {
> dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
> return -ENODEV;
> }
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index 981805a2c521..7f84030c8d53 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c) }
>
> static const struct i2c_device_id da9063_i2c_id[] = {
> - {"da9063", PMIC_DA9063},
> + { "da9063", PMIC_CHIP_ID_DA9063 },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, da9063_i2c_id); diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
> index 6a8f9cd69f52..87c884ae0064 100644
> --- a/drivers/regulator/da9063-regulator.c
> +++ b/drivers/regulator/da9063-regulator.c
> @@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
> {
> .regulator_info = da9063_regulator_info,
> .n_regulators = ARRAY_SIZE(da9063_regulator_info),
> - .dev_model = PMIC_DA9063,
> + .dev_model = PMIC_CHIP_ID_DA9063,
> },
> { }
> };
> diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h index f3ae65db4c86..664f650d0086 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -29,9 +29,7 @@
> #define DA9063_DRVNAME_RTC "da9063-rtc"
> #define DA9063_DRVNAME_VIBRATION "da9063-vibration"
>
> -enum da9063_models {
> - PMIC_DA9063 = 0x61,
> -};
> +#define PMIC_CHIP_ID_DA9063 0x61
>
> enum da9063_variant_codes {
> PMIC_DA9063_AD = 0x3,
> --
> 2.16.2

Acked-by: Steve Twiss <[email protected]>

Regards,
Steve

2018-05-24 21:44:50

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

Hi Marek,

On 24 May 2018 @ 12:49 Steve Twiss wrote:

> To: Marek Vasut <[email protected]>; [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Thanks Marek,
>
> > On 23 May 2018 12:43 Marek Vasut wrote,
> >
> > To: [email protected]
> > Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>;
> > Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> > Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >
> > Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >
>
> There's potentially more to this file. Without an RTC the regmap access tables would change
> and the usual DA9063 (BB silicon) tables would become invalid.
> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
> would need to be updated for DA9063L, if a new chip model was needed.
>
> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>
> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_MON_A10_RES,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_ID_32_31,
> }, {
> .range_min = DA9063_REG_SEQ_A,
> .range_max = DA9063_REG_AUTO3_LOW,
> }, {
> .range_min = DA9063_REG_T_OFFSET,
> .range_max = DA9063_BB_REG_GP_ID_19,
> }, {
> .range_min = DA9063_REG_CHIP_ID,
> .range_max = DA9063_REG_CHIP_VARIANT,
> },
> };
>
> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_PAGE_CON,
> }, {
> .range_min = DA9063_REG_FAULT_LOG,
> .range_max = DA9063_REG_VSYS_MON,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_ID_32_31,
> }, {
> .range_min = DA9063_REG_SEQ_A,
> .range_max = DA9063_REG_AUTO3_LOW,
> }, {
> .range_min = DA9063_REG_CONFIG_I,
> .range_max = DA9063_BB_REG_MON_REG_4,
> }, {
> .range_min = DA9063_BB_REG_GP_ID_0,
> .range_max = DA9063_BB_REG_GP_ID_19,
> },
> };
>
> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_EVENT_D,
> }, {
> .range_min = DA9063_REG_CONTROL_A,
> .range_max = DA9063_REG_CONTROL_B,
> }, {
> .range_min = DA9063_REG_CONTROL_E,
> .range_max = DA9063_REG_CONTROL_F,
> }, {
> .range_min = DA9063_REG_BCORE2_CONT,
> .range_max = DA9063_REG_LDO11_CONT,
> }, {
> .range_min = DA9063_REG_DVC_1,
> .range_max = DA9063_REG_ADC_MAN,
> }, {
> .range_min = DA9063_REG_ADC_RES_L,
> .range_max = DA9063_REG_MON_A10_RES,
> }, {
> .range_min = DA9063_REG_SEQ,
> .range_max = DA9063_REG_SEQ,
> }, {
> .range_min = DA9063_REG_EN_32K,
> .range_max = DA9063_REG_EN_32K,
> }, {
> .range_min = DA9063_BB_REG_MON_REG_5,
> .range_max = DA9063_BB_REG_MON_REG_6,
> },
> };
>
> However this is a larger and more wide-ranging change compared to the one proposed by Marek,
> and would require other alterations to fit this in. Also I'm undecided to what it would really add
> apart from a new chip model: I have been told accessing the DA9063 RTC register locations has no
> effect in the DA9063L.

Looking at this further, there is also a new IRQ regmap.
Again this comes down to whether a full chip model is needed or not. If not, then the IRQ map does not
need to be changed as given. Otherwise the removal of the following:

[DA9063_IRQ_ALARM] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_ALARM,
},
[DA9063_IRQ_TICK] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_TICK,
},

prior to registering the IRQs in the chip model would be needed.
The new regmap_irq would be:

static const struct regmap_irq da9063l_irqs[] = {
/* DA9063 event A register */
[DA9063L_IRQ_ONKEY] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_ONKEY,
},
[DA9063L_IRQ_ADC_RDY] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_ADC_RDY,
},
[DA9063L_IRQ_SEQ_RDY] = {
.reg_offset = DA9063_REG_EVENT_A_OFFSET,
.mask = DA9063_M_SEQ_RDY,
},
/* DA9063 event B register */
[DA9063L_IRQ_WAKE] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_WAKE,
},
[DA9063L_IRQ_TEMP] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_TEMP,
},
[DA9063L_IRQ_COMP_1V2] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_COMP_1V2,
},
[DA9063L_IRQ_LDO_LIM] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_LDO_LIM,
},
[DA9063L_IRQ_REG_UVOV] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_UVOV,
},
[DA9063L_IRQ_DVC_RDY] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_DVC_RDY,
},
[DA9063L_IRQ_VDD_MON] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_VDD_MON,
},
[DA9063L_IRQ_WARN] = {
.reg_offset = DA9063_REG_EVENT_B_OFFSET,
.mask = DA9063_M_VDD_WARN,
},
/* DA9063 event C register */
[DA9063L_IRQ_GPI0] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI0,
},
[DA9063L_IRQ_GPI1] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI1,
},
[DA9063L_IRQ_GPI2] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI2,
},
[DA9063L_IRQ_GPI3] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI3,
},
[DA9063L_IRQ_GPI4] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI4,
},
[DA9063L_IRQ_GPI5] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI5,
},
[DA9063L_IRQ_GPI6] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI6,
},
[DA9063L_IRQ_GPI7] = {
.reg_offset = DA9063_REG_EVENT_C_OFFSET,
.mask = DA9063_M_GPI7,
},
/* DA9063 event D register */
[DA9063L_IRQ_GPI8] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI8,
},
[DA9063L_IRQ_GPI9] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI9,
},
[DA9063L_IRQ_GPI10] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI10,
},
[DA9063L_IRQ_GPI11] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI11,
},
[DA9063L_IRQ_GPI12] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI12,
},
[DA9063L_IRQ_GPI13] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI13,
},
[DA9063L_IRQ_GPI14] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI14,
},
[DA9063L_IRQ_GPI15] = {
.reg_offset = DA9063_REG_EVENT_D_OFFSET,
.mask = DA9063_M_GPI15,
},
};

Regards,
Steve

>
> If the maintainers are happy with this, and if a chip model addition is really needed in future it can
> be added later if required.
>
> Acked-by: Steve Twiss <[email protected]>
>
> Regards,
> Steve

> > Signed-off-by: Marek Vasut <[email protected]>
> > Cc: Geert Uytterhoeven <[email protected]>
> > Cc: Lee Jones <[email protected]>
> > Cc: Mark Brown <[email protected]>
> > Cc: Steve Twiss <[email protected]>
> > Cc: Wolfram Sang <[email protected]>
> > Cc: [email protected]
> > ---
> > drivers/mfd/da9063-i2c.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index
> > 5544ce8e3363..84bbd2bbcd2a 100644
> > --- a/drivers/mfd/da9063-i2c.c
> > +++ b/drivers/mfd/da9063-i2c.c
> > @@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config =
> > {
> >
> > static const struct of_device_id da9063_dt_ids[] = {
> > { .compatible = "dlg,da9063", },
> > + { .compatible = "dlg,da9063l", },
> > { }
> > };
> > MODULE_DEVICE_TABLE(of, da9063_dt_ids); @@ -282,6 +283,7 @@ static
> > int da9063_i2c_remove(struct i2c_client *i2c)
> >
> > static const struct i2c_device_id da9063_i2c_id[] = {
> > { "da9063", PMIC_TYPE_DA9063 },
> > + { "da9063l", PMIC_TYPE_DA9063L },
> > {},
> > };
> > MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
> > --
> > 2.16.2


2018-05-24 22:43:53

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

Thanks Marek,

On 23 May 2018 12:42 Marek Vasut wrote,

> To: [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
>
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Lee Jones <[email protected]>
> Cc: Mark Brown <[email protected]>
> Cc: Steve Twiss <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> ---
> drivers/mfd/da9063-core.c | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
> .of_compatible = "dlg,da9063-onkey",
> },
> {
> + .name = DA9063_DRVNAME_VIBRATION,
> + },
> + { /* Only present on DA9063 , not on DA9063L */
> .name = DA9063_DRVNAME_RTC,
> .num_resources = ARRAY_SIZE(da9063_rtc_resources),
> .resources = da9063_rtc_resources,
> .of_compatible = "dlg,da9063-rtc",
> },
> - {
> - .name = DA9063_DRVNAME_VIBRATION,
> - },
> };
>
> static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq) {
> struct da9063_pdata *pdata = da9063->dev->platform_data;
> int model, variant_id, variant_code;
> - int ret;
> + int da9063_devs_len, ret;
>
> ret = da9063_clear_fault_log(da9063);
> if (ret < 0)
> @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
>
> da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
>
> - ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
> - ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
> - NULL);
> + da9063_devs_len = ARRAY_SIZE(da9063_devs);
> + /* RTC, the last device in the list, is only present on DA9063 */
> + if (da9063->type == PMIC_TYPE_DA9063L)
> + da9063_devs_len -= 1;
> +
> + ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
> + NULL, da9063->irq_base, NULL);
> if (ret)
> dev_err(da9063->dev, "Cannot add MFD cells\n");
>
> --
> 2.16.2

MFD cells definitely has less impact than regmap_range and regmap_irq.
I agree, there's no point in having a completely new
static const struct mfd_cell da9063l_devs[] = { ... } for DA9063L

Acked-by: Steve Twiss <[email protected]>

Regards,
Steve

2018-05-24 22:59:59

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 3/6] mfd: da9063: Add DA9063L type

On 23 May 2018 12:42 Marek Vasut wrote:

> To: [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> Subject: [PATCH 3/6] mfd: da9063: Add DA9063L type
>
> Add type for DA9063L, which is a reduced variant of the DA9063 without RTC block and with less regulators.
>
> Signed-off-by: Marek Vasut <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Lee Jones <[email protected]>
> Cc: Mark Brown <[email protected]>
> Cc: Steve Twiss <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> ---
> include/linux/mfd/da9063/core.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h index eb234582dcb2..c3e917dd1860 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -33,6 +33,7 @@
>
> enum da9063_type {
> PMIC_TYPE_DA9063 = 0,
> + PMIC_TYPE_DA9063L,
> };
>
> enum da9063_variant_codes {
> --
> 2.16.2

Acked-by: Steve Twiss <[email protected]>

Regards,
Steve

2018-05-25 02:19:18

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 05/24/2018 02:32 PM, Steve Twiss wrote:
> Hi Marek,
>
> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>
>> To: Marek Vasut <[email protected]>; [email protected]
>> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
>> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>
>> Thanks Marek,
>>
>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>
>>> To: [email protected]
>>> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>;
>>> Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>
>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>
>>
>> There's potentially more to this file. Without an RTC the regmap access tables would change
>> and the usual DA9063 (BB silicon) tables would become invalid.
>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
>> would need to be updated for DA9063L, if a new chip model was needed.
>>
>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>
>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>> {
>> .range_min = DA9063_REG_PAGE_CON,
>> .range_max = DA9063_REG_MON_A10_RES,
>> }, {
>> .range_min = DA9063_REG_SEQ,
>> .range_max = DA9063_REG_ID_32_31,
>> }, {
>> .range_min = DA9063_REG_SEQ_A,
>> .range_max = DA9063_REG_AUTO3_LOW,
>> }, {
>> .range_min = DA9063_REG_T_OFFSET,
>> .range_max = DA9063_BB_REG_GP_ID_19,
>> }, {
>> .range_min = DA9063_REG_CHIP_ID,
>> .range_max = DA9063_REG_CHIP_VARIANT,
>> },
>> };
>>
>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>> {
>> .range_min = DA9063_REG_PAGE_CON,
>> .range_max = DA9063_REG_PAGE_CON,
>> }, {
>> .range_min = DA9063_REG_FAULT_LOG,
>> .range_max = DA9063_REG_VSYS_MON,
>> }, {
>> .range_min = DA9063_REG_SEQ,
>> .range_max = DA9063_REG_ID_32_31,
>> }, {
>> .range_min = DA9063_REG_SEQ_A,
>> .range_max = DA9063_REG_AUTO3_LOW,
>> }, {
>> .range_min = DA9063_REG_CONFIG_I,
>> .range_max = DA9063_BB_REG_MON_REG_4,
>> }, {
>> .range_min = DA9063_BB_REG_GP_ID_0,
>> .range_max = DA9063_BB_REG_GP_ID_19,
>> },
>> };
>>
>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>> {
>> .range_min = DA9063_REG_PAGE_CON,
>> .range_max = DA9063_REG_EVENT_D,
>> }, {
>> .range_min = DA9063_REG_CONTROL_A,
>> .range_max = DA9063_REG_CONTROL_B,
>> }, {
>> .range_min = DA9063_REG_CONTROL_E,
>> .range_max = DA9063_REG_CONTROL_F,
>> }, {
>> .range_min = DA9063_REG_BCORE2_CONT,
>> .range_max = DA9063_REG_LDO11_CONT,
>> }, {
>> .range_min = DA9063_REG_DVC_1,
>> .range_max = DA9063_REG_ADC_MAN,
>> }, {
>> .range_min = DA9063_REG_ADC_RES_L,
>> .range_max = DA9063_REG_MON_A10_RES,
>> }, {
>> .range_min = DA9063_REG_SEQ,
>> .range_max = DA9063_REG_SEQ,
>> }, {
>> .range_min = DA9063_REG_EN_32K,
>> .range_max = DA9063_REG_EN_32K,
>> }, {
>> .range_min = DA9063_BB_REG_MON_REG_5,
>> .range_max = DA9063_BB_REG_MON_REG_6,
>> },
>> };
>>
>> However this is a larger and more wide-ranging change compared to the one proposed by Marek,
>> and would require other alterations to fit this in. Also I'm undecided to what it would really add
>> apart from a new chip model: I have been told accessing the DA9063 RTC register locations has no
>> effect in the DA9063L.
>
> Looking at this further, there is also a new IRQ regmap.
> Again this comes down to whether a full chip model is needed or not. If not, then the IRQ map does not
> need to be changed as given. Otherwise the removal of the following:
>
> [DA9063_IRQ_ALARM] = {
> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> .mask = DA9063_M_ALARM,
> },
> [DA9063_IRQ_TICK] = {
> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> .mask = DA9063_M_TICK,
> },
>
> prior to registering the IRQs in the chip model would be needed.
> The new regmap_irq would be:
>
> static const struct regmap_irq da9063l_irqs[] = {
> /* DA9063 event A register */
> [DA9063L_IRQ_ONKEY] = {
> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> .mask = DA9063_M_ONKEY,
> },
> [DA9063L_IRQ_ADC_RDY] = {
> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> .mask = DA9063_M_ADC_RDY,
> },
> [DA9063L_IRQ_SEQ_RDY] = {
> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> .mask = DA9063_M_SEQ_RDY,
> },
> /* DA9063 event B register */
> [DA9063L_IRQ_WAKE] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_WAKE,
> },
> [DA9063L_IRQ_TEMP] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_TEMP,
> },
> [DA9063L_IRQ_COMP_1V2] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_COMP_1V2,
> },
> [DA9063L_IRQ_LDO_LIM] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_LDO_LIM,
> },
> [DA9063L_IRQ_REG_UVOV] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_UVOV,
> },
> [DA9063L_IRQ_DVC_RDY] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_DVC_RDY,
> },
> [DA9063L_IRQ_VDD_MON] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_VDD_MON,
> },
> [DA9063L_IRQ_WARN] = {
> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> .mask = DA9063_M_VDD_WARN,
> },
> /* DA9063 event C register */
> [DA9063L_IRQ_GPI0] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI0,
> },
> [DA9063L_IRQ_GPI1] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI1,
> },
> [DA9063L_IRQ_GPI2] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI2,
> },
> [DA9063L_IRQ_GPI3] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI3,
> },
> [DA9063L_IRQ_GPI4] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI4,
> },
> [DA9063L_IRQ_GPI5] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI5,
> },
> [DA9063L_IRQ_GPI6] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI6,
> },
> [DA9063L_IRQ_GPI7] = {
> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> .mask = DA9063_M_GPI7,
> },
> /* DA9063 event D register */
> [DA9063L_IRQ_GPI8] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI8,
> },
> [DA9063L_IRQ_GPI9] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI9,
> },
> [DA9063L_IRQ_GPI10] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI10,
> },
> [DA9063L_IRQ_GPI11] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI11,
> },
> [DA9063L_IRQ_GPI12] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI12,
> },
> [DA9063L_IRQ_GPI13] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI13,
> },
> [DA9063L_IRQ_GPI14] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI14,
> },
> [DA9063L_IRQ_GPI15] = {
> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> .mask = DA9063_M_GPI15,
> },
> };

We can probably do the same trick with the regmaps and irqmaps as with
the rest, that is, reorder them and register only a smaller portion ?

--
Best regards,
Marek Vasut

2018-05-25 02:34:43

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 24 May 2018 15:51 Marek Vasut wrote:

Hi Marek,

> To: Steve Twiss <[email protected]>; [email protected]
> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven
> <[email protected]>; Lee Jones <[email protected]>; Mark Brown
> <[email protected]>; Wolfram Sang <[email protected]>;
> [email protected]
> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> > On 24 May 2018 @ 12:49 Steve Twiss wrote:
> >>> On 23 May 2018 12:43 Marek Vasut wrote,
> >>>
> >>> To: [email protected]
> >>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>>
> >>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >>>
> >>
> >> There's potentially more to this file. Without an RTC the regmap
> >> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
> >> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> >> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
> >>
> >> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
> >>
> >> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> >> {
> >> .range_min = DA9063_REG_PAGE_CON,
> >> .range_max = DA9063_REG_MON_A10_RES,
> >> }, {
> >> .range_min = DA9063_REG_SEQ,
> >> .range_max = DA9063_REG_ID_32_31,
> >> }, {
> >> .range_min = DA9063_REG_SEQ_A,
> >> .range_max = DA9063_REG_AUTO3_LOW,
> >> }, {
> >> .range_min = DA9063_REG_T_OFFSET,
> >> .range_max = DA9063_BB_REG_GP_ID_19,
> >> }, {
> >> .range_min = DA9063_REG_CHIP_ID,
> >> .range_max = DA9063_REG_CHIP_VARIANT,
> >> },
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> >> {
> >> .range_min = DA9063_REG_PAGE_CON,
> >> .range_max = DA9063_REG_PAGE_CON,
> >> }, {
> >> .range_min = DA9063_REG_FAULT_LOG,
> >> .range_max = DA9063_REG_VSYS_MON,
> >> }, {
> >> .range_min = DA9063_REG_SEQ,
> >> .range_max = DA9063_REG_ID_32_31,
> >> }, {
> >> .range_min = DA9063_REG_SEQ_A,
> >> .range_max = DA9063_REG_AUTO3_LOW,
> >> }, {
> >> .range_min = DA9063_REG_CONFIG_I,
> >> .range_max = DA9063_BB_REG_MON_REG_4,
> >> }, {
> >> .range_min = DA9063_BB_REG_GP_ID_0,
> >> .range_max = DA9063_BB_REG_GP_ID_19,
> >> },
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> >> {
> >> .range_min = DA9063_REG_PAGE_CON,
> >> .range_max = DA9063_REG_EVENT_D,
> >> }, {
> >> .range_min = DA9063_REG_CONTROL_A,
> >> .range_max = DA9063_REG_CONTROL_B,
> >> }, {
> >> .range_min = DA9063_REG_CONTROL_E,
> >> .range_max = DA9063_REG_CONTROL_F,
> >> }, {
> >> .range_min = DA9063_REG_BCORE2_CONT,
> >> .range_max = DA9063_REG_LDO11_CONT,
> >> }, {
> >> .range_min = DA9063_REG_DVC_1,
> >> .range_max = DA9063_REG_ADC_MAN,
> >> }, {
> >> .range_min = DA9063_REG_ADC_RES_L,
> >> .range_max = DA9063_REG_MON_A10_RES,
> >> }, {
> >> .range_min = DA9063_REG_SEQ,
> >> .range_max = DA9063_REG_SEQ,
> >> }, {
> >> .range_min = DA9063_REG_EN_32K,
> >> .range_max = DA9063_REG_EN_32K,
> >> }, {
> >> .range_min = DA9063_BB_REG_MON_REG_5,
> >> .range_max = DA9063_BB_REG_MON_REG_6,
> >> },
> >> };
> >>
> >> However this is a larger and more wide-ranging change compared to the
> >> one proposed by Marek, and would require other alterations to fit
> >> this in. Also I'm undecided to what it would really add apart from a
> >> new chip model: I have been told accessing the DA9063 RTC register locations
> >> has no effect in the DA9063L.
> >
> > Looking at this further, there is also a new IRQ regmap.
> > Again this comes down to whether a full chip model is needed or not.
> > If not, then the IRQ map does not need to be changed as given. Otherwise the
> > removal of the following:
> >
> > [DA9063_IRQ_ALARM] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_ALARM,
> > },
> > [DA9063_IRQ_TICK] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_TICK,
> > },
> >
> > prior to registering the IRQs in the chip model would be needed.
> > The new regmap_irq would be:
> >
> > static const struct regmap_irq da9063l_irqs[] = {
> > /* DA9063 event A register */
> > [DA9063L_IRQ_ONKEY] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_ONKEY,
> > },
> > [DA9063L_IRQ_ADC_RDY] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_ADC_RDY,
> > },
> > [DA9063L_IRQ_SEQ_RDY] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_SEQ_RDY,
> > },
> > /* DA9063 event B register */
> > [DA9063L_IRQ_WAKE] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_WAKE,
> > },
> > [DA9063L_IRQ_TEMP] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_TEMP,
> > },
> > [DA9063L_IRQ_COMP_1V2] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_COMP_1V2,
> > },
> > [DA9063L_IRQ_LDO_LIM] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_LDO_LIM,
> > },
> > [DA9063L_IRQ_REG_UVOV] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_UVOV,
> > },
> > [DA9063L_IRQ_DVC_RDY] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_DVC_RDY,
> > },
> > [DA9063L_IRQ_VDD_MON] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_VDD_MON,
> > },
> > [DA9063L_IRQ_WARN] = {
> > .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > .mask = DA9063_M_VDD_WARN,
> > },
> > /* DA9063 event C register */
> > [DA9063L_IRQ_GPI0] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI0,
> > },
> > [DA9063L_IRQ_GPI1] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI1,
> > },
> > [DA9063L_IRQ_GPI2] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI2,
> > },
> > [DA9063L_IRQ_GPI3] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI3,
> > },
> > [DA9063L_IRQ_GPI4] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI4,
> > },
> > [DA9063L_IRQ_GPI5] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI5,
> > },
> > [DA9063L_IRQ_GPI6] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI6,
> > },
> > [DA9063L_IRQ_GPI7] = {
> > .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > .mask = DA9063_M_GPI7,
> > },
> > /* DA9063 event D register */
> > [DA9063L_IRQ_GPI8] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI8,
> > },
> > [DA9063L_IRQ_GPI9] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI9,
> > },
> > [DA9063L_IRQ_GPI10] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI10,
> > },
> > [DA9063L_IRQ_GPI11] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI11,
> > },
> > [DA9063L_IRQ_GPI12] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI12,
> > },
> > [DA9063L_IRQ_GPI13] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI13,
> > },
> > [DA9063L_IRQ_GPI14] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI14,
> > },
> > [DA9063L_IRQ_GPI15] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI15,
> > },
> > };
>
> We can probably do the same trick with the regmaps and irqmaps as with the
> rest, that is, reorder them and register only a smaller portion ?

I like the "reorder and only register a smaller portion" trick. But it wouldn't work
with what I gave earlier today, without some modification.
For instance, the first register readable entry range in the DA9063 BB is:

static const struct regmap_range da9063_bb_readable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_BB_REG_SECOND_D,
}, {

But for the DA9063L, this first range entry would be changed, not removed:

static const struct regmap_range da9063l_bb_readable_ranges[] = {
{
.range_min = DA9063_REG_PAGE_CON,
.range_max = DA9063_REG_MON_A10_RES,
}, {

So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
into two pieces.

However, it might get messy to maintain in future -- sometimes register ranges need to be
updated with new components or if a new feature is added -- usually I need to work it
all out on paper with the full register map. Splitting up ranges might make it a little
messier. But, it's not impossible.

For the DA9062 and DA9061 this was done using separate ranges and using the macro
regmap_reg_range(). It's not that messy to read, e.g.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367

Regards,
Steve

2018-05-26 09:19:06

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x002-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64

All warnings (new ones prefixed by >>):

In file included from include/linux/kernel.h:10:0,
from drivers//regulator/da9063-regulator.c:16:
drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
______r = !!(cond); \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
da9063->model);
^~

vim +/if +744 drivers//regulator/da9063-regulator.c

715
716 static int da9063_regulator_probe(struct platform_device *pdev)
717 {
718 struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
719 struct da9063_pdata *da9063_pdata = dev_get_platdata(da9063->dev);
720 struct of_regulator_match *da9063_reg_matches = NULL;
721 struct da9063_regulators_pdata *regl_pdata;
722 const struct da9063_dev_model *model;
723 struct da9063_regulators *regulators;
724 struct da9063_regulator *regl;
725 struct regulator_config config;
726 bool bcores_merged, bmem_bio_merged;
727 int id, irq, n, n_regulators, ret, val;
728 size_t size;
729
730 regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata : NULL;
731
732 if (!regl_pdata)
733 regl_pdata = da9063_parse_regulators_dt(pdev,
734 &da9063_reg_matches);
735
736 if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
737 dev_err(&pdev->dev,
738 "No regulators defined for the platform\n");
739 return -ENODEV;
740 }
741
742 /* Find regulators set for particular device model */
743 for (model = regulators_models; model->regulator_info; model++) {
> 744 if (model->dev_model == da9063->type)
745 break;
746 }
747 if (!model->regulator_info) {
748 dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
749 da9063->model);
750 return -ENODEV;
751 }
752
753 ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
754 if (ret < 0) {
755 dev_err(&pdev->dev,
756 "Error while reading BUCKs configuration\n");
757 return ret;
758 }
759 bcores_merged = val & DA9063_BCORE_MERGE;
760 bmem_bio_merged = val & DA9063_BUCK_MERGE;
761
762 n_regulators = model->n_regulators;
763 if (bcores_merged)
764 n_regulators -= 2; /* remove BCORE1, BCORE2 */
765 else
766 n_regulators--; /* remove BCORES_MERGED */
767 if (bmem_bio_merged)
768 n_regulators -= 2; /* remove BMEM, BIO */
769 else
770 n_regulators--; /* remove BMEM_BIO_MERGED */
771
772 /* Allocate memory required by usable regulators */
773 size = sizeof(struct da9063_regulators) +
774 n_regulators * sizeof(struct da9063_regulator);
775 regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
776 if (!regulators)
777 return -ENOMEM;
778
779 regulators->n_regulators = n_regulators;
780 platform_set_drvdata(pdev, regulators);
781
782 /* Register all regulators declared in platform information */
783 n = 0;
784 id = 0;
785 while (n < regulators->n_regulators) {
786 /* Skip regulator IDs depending on merge mode configuration */
787 switch (id) {
788 case DA9063_ID_BCORE1:
789 case DA9063_ID_BCORE2:
790 if (bcores_merged) {
791 id++;
792 continue;
793 }
794 break;
795 case DA9063_ID_BMEM:
796 case DA9063_ID_BIO:
797 if (bmem_bio_merged) {
798 id++;
799 continue;
800 }
801 break;
802 case DA9063_ID_BCORES_MERGED:
803 if (!bcores_merged) {
804 id++;
805 continue;
806 }
807 break;
808 case DA9063_ID_BMEM_BIO_MERGED:
809 if (!bmem_bio_merged) {
810 id++;
811 continue;
812 }
813 break;
814 }
815
816 /* Initialise regulator structure */
817 regl = &regulators->regulator[n];
818 regl->hw = da9063;
819 regl->info = &model->regulator_info[id];
820 regl->desc = regl->info->desc;
821 regl->desc.type = REGULATOR_VOLTAGE;
822 regl->desc.owner = THIS_MODULE;
823
824 if (regl->info->mode.reg)
825 regl->mode = devm_regmap_field_alloc(&pdev->dev,
826 da9063->regmap, regl->info->mode);
827 if (regl->info->suspend.reg)
828 regl->suspend = devm_regmap_field_alloc(&pdev->dev,
829 da9063->regmap, regl->info->suspend);
830 if (regl->info->sleep.reg)
831 regl->sleep = devm_regmap_field_alloc(&pdev->dev,
832 da9063->regmap, regl->info->sleep);
833 if (regl->info->suspend_sleep.reg)
834 regl->suspend_sleep = devm_regmap_field_alloc(&pdev->dev,
835 da9063->regmap, regl->info->suspend_sleep);
836 if (regl->info->ilimit.reg)
837 regl->ilimit = devm_regmap_field_alloc(&pdev->dev,
838 da9063->regmap, regl->info->ilimit);
839
840 /* Register regulator */
841 memset(&config, 0, sizeof(config));
842 config.dev = &pdev->dev;
843 config.init_data = da9063_get_regulator_initdata(regl_pdata, id);
844 config.driver_data = regl;
845 if (da9063_reg_matches)
846 config.of_node = da9063_reg_matches[id].of_node;
847 config.regmap = da9063->regmap;
848 regl->rdev = devm_regulator_register(&pdev->dev, &regl->desc,
849 &config);
850 if (IS_ERR(regl->rdev)) {
851 dev_err(&pdev->dev,
852 "Failed to register %s regulator\n",
853 regl->desc.name);
854 return PTR_ERR(regl->rdev);
855 }
856 id++;
857 n++;
858 }
859
860 /* LDOs overcurrent event support */
861 irq = platform_get_irq_byname(pdev, "LDO_LIM");
862 if (irq < 0) {
863 dev_err(&pdev->dev, "Failed to get IRQ.\n");
864 return irq;
865 }
866
867 ret = devm_request_threaded_irq(&pdev->dev, irq,
868 NULL, da9063_ldo_lim_event,
869 IRQF_TRIGGER_LOW | IRQF_ONESHOT,
870 "LDO_LIM", regulators);
871 if (ret) {
872 dev_err(&pdev->dev, "Failed to request LDO_LIM IRQ.\n");
873 return ret;
874 }
875
876 return 0;
877 }
878

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation


Attachments:
(No filename) (8.36 kB)
.config.gz (28.97 kB)
Download all attachments

2018-05-26 09:59:17

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

On 05/26/2018 11:16 AM, kbuild test robot wrote:
> Hi Marek,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on ljones-mfd/for-mfd-next]
> [also build test WARNING on v4.17-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
> config: x86_64-randconfig-x002-201820 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
> In file included from include/linux/kernel.h:10:0,
> from drivers//regulator/da9063-regulator.c:16:
> drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
> if (model->dev_model == da9063->type)
> ^
> include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
> ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
> if (model->dev_model == da9063->type)
> ^~
> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
> if (model->dev_model == da9063->type)
> ^
> include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
> ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
> if (model->dev_model == da9063->type)
> ^~
> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
> if (model->dev_model == da9063->type)
> ^
> include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
> ______r = !!(cond); \
> ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
> if (model->dev_model == da9063->type)
> ^~
> drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
> da9063->model);
> ^~
>
> vim +/if +744 drivers//regulator/da9063-regulator.c

Is it testing this patch without the other patches in the series or at
least 1/6 ?

--
Best regards,
Marek Vasut

2018-05-26 11:03:32

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

Hi Marek,

I love your patch! Yet something to improve:

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url: https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x011-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64

All errors (new ones prefixed by >>):

drivers/regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>> drivers/regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^~
>> drivers/regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
da9063->model);
^~

vim +744 drivers/regulator/da9063-regulator.c

715
716 static int da9063_regulator_probe(struct platform_device *pdev)
717 {
718 struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
719 struct da9063_pdata *da9063_pdata = dev_get_platdata(da9063->dev);
720 struct of_regulator_match *da9063_reg_matches = NULL;
721 struct da9063_regulators_pdata *regl_pdata;
722 const struct da9063_dev_model *model;
723 struct da9063_regulators *regulators;
724 struct da9063_regulator *regl;
725 struct regulator_config config;
726 bool bcores_merged, bmem_bio_merged;
727 int id, irq, n, n_regulators, ret, val;
728 size_t size;
729
730 regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata : NULL;
731
732 if (!regl_pdata)
733 regl_pdata = da9063_parse_regulators_dt(pdev,
734 &da9063_reg_matches);
735
736 if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
737 dev_err(&pdev->dev,
738 "No regulators defined for the platform\n");
739 return -ENODEV;
740 }
741
742 /* Find regulators set for particular device model */
743 for (model = regulators_models; model->regulator_info; model++) {
> 744 if (model->dev_model == da9063->type)
745 break;
746 }
747 if (!model->regulator_info) {
748 dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
> 749 da9063->model);
750 return -ENODEV;
751 }
752
753 ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
754 if (ret < 0) {
755 dev_err(&pdev->dev,
756 "Error while reading BUCKs configuration\n");
757 return ret;
758 }
759 bcores_merged = val & DA9063_BCORE_MERGE;
760 bmem_bio_merged = val & DA9063_BUCK_MERGE;
761
762 n_regulators = model->n_regulators;
763 if (bcores_merged)
764 n_regulators -= 2; /* remove BCORE1, BCORE2 */
765 else
766 n_regulators--; /* remove BCORES_MERGED */
767 if (bmem_bio_merged)
768 n_regulators -= 2; /* remove BMEM, BIO */
769 else
770 n_regulators--; /* remove BMEM_BIO_MERGED */
771
772 /* Allocate memory required by usable regulators */
773 size = sizeof(struct da9063_regulators) +
774 n_regulators * sizeof(struct da9063_regulator);
775 regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
776 if (!regulators)
777 return -ENOMEM;
778
779 regulators->n_regulators = n_regulators;
780 platform_set_drvdata(pdev, regulators);
781
782 /* Register all regulators declared in platform information */
783 n = 0;
784 id = 0;
785 while (n < regulators->n_regulators) {
786 /* Skip regulator IDs depending on merge mode configuration */
787 switch (id) {
788 case DA9063_ID_BCORE1:
789 case DA9063_ID_BCORE2:
790 if (bcores_merged) {
791 id++;
792 continue;
793 }
794 break;
795 case DA9063_ID_BMEM:
796 case DA9063_ID_BIO:
797 if (bmem_bio_merged) {
798 id++;
799 continue;
800 }
801 break;
802 case DA9063_ID_BCORES_MERGED:
803 if (!bcores_merged) {
804 id++;
805 continue;
806 }
807 break;
808 case DA9063_ID_BMEM_BIO_MERGED:
809 if (!bmem_bio_merged) {
810 id++;
811 continue;
812 }
813 break;
814 }
815
816 /* Initialise regulator structure */
817 regl = &regulators->regulator[n];
818 regl->hw = da9063;
819 regl->info = &model->regulator_info[id];
820 regl->desc = regl->info->desc;
821 regl->desc.type = REGULATOR_VOLTAGE;
822 regl->desc.owner = THIS_MODULE;
823
824 if (regl->info->mode.reg)
825 regl->mode = devm_regmap_field_alloc(&pdev->dev,
826 da9063->regmap, regl->info->mode);
827 if (regl->info->suspend.reg)
828 regl->suspend = devm_regmap_field_alloc(&pdev->dev,
829 da9063->regmap, regl->info->suspend);
830 if (regl->info->sleep.reg)
831 regl->sleep = devm_regmap_field_alloc(&pdev->dev,
832 da9063->regmap, regl->info->sleep);
833 if (regl->info->suspend_sleep.reg)
834 regl->suspend_sleep = devm_regmap_field_alloc(&pdev->dev,
835 da9063->regmap, regl->info->suspend_sleep);
836 if (regl->info->ilimit.reg)
837 regl->ilimit = devm_regmap_field_alloc(&pdev->dev,
838 da9063->regmap, regl->info->ilimit);
839
840 /* Register regulator */
841 memset(&config, 0, sizeof(config));
842 config.dev = &pdev->dev;
843 config.init_data = da9063_get_regulator_initdata(regl_pdata, id);
844 config.driver_data = regl;
845 if (da9063_reg_matches)
846 config.of_node = da9063_reg_matches[id].of_node;
847 config.regmap = da9063->regmap;
848 regl->rdev = devm_regulator_register(&pdev->dev, &regl->desc,
849 &config);
850 if (IS_ERR(regl->rdev)) {
851 dev_err(&pdev->dev,
852 "Failed to register %s regulator\n",
853 regl->desc.name);
854 return PTR_ERR(regl->rdev);
855 }
856 id++;
857 n++;
858 }
859
860 /* LDOs overcurrent event support */
861 irq = platform_get_irq_byname(pdev, "LDO_LIM");
862 if (irq < 0) {
863 dev_err(&pdev->dev, "Failed to get IRQ.\n");
864 return irq;
865 }
866
867 ret = devm_request_threaded_irq(&pdev->dev, irq,
868 NULL, da9063_ldo_lim_event,
869 IRQF_TRIGGER_LOW | IRQF_ONESHOT,
870 "LDO_LIM", regulators);
871 if (ret) {
872 dev_err(&pdev->dev, "Failed to request LDO_LIM IRQ.\n");
873 return ret;
874 }
875
876 return 0;
877 }
878

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation


Attachments:
(No filename) (6.98 kB)
.config.gz (32.14 kB)
Download all attachments

2018-05-29 07:48:08

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On Thu, 24 May 2018, Marek Vasut wrote:
> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> > On 24 May 2018 @ 12:49 Steve Twiss wrote:

[...]

> > static const struct regmap_irq da9063l_irqs[] = {
> > /* DA9063 event A register */
> > [DA9063L_IRQ_ONKEY] = {
> > .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > .mask = DA9063_M_ONKEY,
> > },

[...]

> > [DA9063L_IRQ_GPI15] = {
> > .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > .mask = DA9063_M_GPI15,
> > },
> > };
>
> We can probably do the same trick with the regmaps and irqmaps as with
> the rest, that is, reorder them and register only a smaller portion ?

Please also consider using REGMAP_IRQ_REG().

--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2018-05-29 07:55:59

by Lee Jones

[permalink] [raw]
Subject: Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

On Thu, 24 May 2018, Steve Twiss wrote:

> Thanks Marek,
>
> On 23 May 2018 12:42 Marek Vasut wrote,
>
> > To: [email protected]
> > Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
> > Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
> >
> > The DA9063L does not contain RTC block, unlike the full DA9063.
> > Do not allow binding RTC driver on this variant of the chip.
> >
> > Signed-off-by: Marek Vasut <[email protected]>
> > Cc: Geert Uytterhoeven <[email protected]>
> > Cc: Lee Jones <[email protected]>
> > Cc: Mark Brown <[email protected]>
> > Cc: Steve Twiss <[email protected]>
> > Cc: Wolfram Sang <[email protected]>
> > Cc: [email protected]
> > ---
> > drivers/mfd/da9063-core.c | 18 +++++++++++-------
> > 1 file changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
> > --- a/drivers/mfd/da9063-core.c
> > +++ b/drivers/mfd/da9063-core.c
> > @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
> > .of_compatible = "dlg,da9063-onkey",
> > },
> > {
> > + .name = DA9063_DRVNAME_VIBRATION,
> > + },
> > + { /* Only present on DA9063 , not on DA9063L */
> > .name = DA9063_DRVNAME_RTC,
> > .num_resources = ARRAY_SIZE(da9063_rtc_resources),
> > .resources = da9063_rtc_resources,
> > .of_compatible = "dlg,da9063-rtc",
> > },
> > - {
> > - .name = DA9063_DRVNAME_VIBRATION,
> > - },
> > };
> >
> > static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq) {
> > struct da9063_pdata *pdata = da9063->dev->platform_data;
> > int model, variant_id, variant_code;
> > - int ret;
> > + int da9063_devs_len, ret;
> >
> > ret = da9063_clear_fault_log(da9063);
> > if (ret < 0)
> > @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
> >
> > da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
> >
> > - ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
> > - ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
> > - NULL);
> > + da9063_devs_len = ARRAY_SIZE(da9063_devs);
> > + /* RTC, the last device in the list, is only present on DA9063 */
> > + if (da9063->type == PMIC_TYPE_DA9063L)
> > + da9063_devs_len -= 1;
> > +
> > + ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
> > + NULL, da9063->irq_base, NULL);
> > if (ret)
> > dev_err(da9063->dev, "Cannot add MFD cells\n");
> >
>
> MFD cells definitely has less impact than regmap_range and regmap_irq.
> I agree, there's no point in having a completely new
> static const struct mfd_cell da9063l_devs[] = { ... } for DA9063L

This solution is fragile.

I agree that a new MFD cell is not required in its entirety. It
would however, be better to split out the RTC entry into a new one and
only register it when (da9063->type == PMIC_TYPE_DA9063). This is a
better solution than messing around with passed struct sizes.

--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

2018-05-30 05:26:09

by kernel test robot

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

Hi, Marek

On 05/26, Marek Vasut wrote:
>On 05/26/2018 11:16 AM, kbuild test robot wrote:
>> Hi Marek,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on ljones-mfd/for-mfd-next]
>> [also build test WARNING on v4.17-rc6]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>
>> url: https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
>> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
>> config: x86_64-randconfig-x002-201820 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All warnings (new ones prefixed by >>):
>>
>> In file included from include/linux/kernel.h:10:0,
>> from drivers//regulator/da9063-regulator.c:16:
>> drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>> if (model->dev_model == da9063->type)
>> ^
>> include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
>> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
>> ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>> if (model->dev_model == da9063->type)
>> ^~
>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>> if (model->dev_model == da9063->type)
>> ^
>> include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
>> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
>> ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>> if (model->dev_model == da9063->type)
>> ^~
>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>> if (model->dev_model == da9063->type)
>> ^
>> include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
>> ______r = !!(cond); \
>> ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>> if (model->dev_model == da9063->type)
>> ^~
>> drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
>> da9063->model);
>> ^~
>>
>> vim +/if +744 drivers//regulator/da9063-regulator.c
>
>Is it testing this patch without the other patches in the series or at
>least 1/6 ?

It was tested with the whole patch series as you can see in https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613.


Thanks,
Xiaolong
>
>--
>Best regards,
>Marek Vasut
>

2018-05-30 11:02:39

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 2/6] mfd: da9063: Replace model with type

On 05/30/2018 07:21 AM, Ye Xiaolong wrote:
> Hi, Marek
>
> On 05/26, Marek Vasut wrote:
>> On 05/26/2018 11:16 AM, kbuild test robot wrote:
>>> Hi Marek,
>>>
>>> I love your patch! Perhaps something to improve:
>>>
>>> [auto build test WARNING on ljones-mfd/for-mfd-next]
>>> [also build test WARNING on v4.17-rc6]
>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>>
>>> url: https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
>>> config: x86_64-randconfig-x002-201820 (attached as .config)
>>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>>> reproduce:
>>> # save the attached .config to linux build tree
>>> make ARCH=x86_64
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>> In file included from include/linux/kernel.h:10:0,
>>> from drivers//regulator/da9063-regulator.c:16:
>>> drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>> if (model->dev_model == da9063->type)
>>> ^
>>> include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
>>> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
>>> ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>> if (model->dev_model == da9063->type)
>>> ^~
>>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>> if (model->dev_model == da9063->type)
>>> ^
>>> include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
>>> if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
>>> ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>> if (model->dev_model == da9063->type)
>>> ^~
>>> drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>> if (model->dev_model == da9063->type)
>>> ^
>>> include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
>>> ______r = !!(cond); \
>>> ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>> if (model->dev_model == da9063->type)
>>> ^~
>>> drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
>>> da9063->model);
>>> ^~
>>>
>>> vim +/if +744 drivers//regulator/da9063-regulator.c
>>
>> Is it testing this patch without the other patches in the series or at
>> least 1/6 ?
>
> It was tested with the whole patch series as you can see in https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613.

Ha, I see the problem. Thanks for confirming it's checked with the whole
series.

--
Best regards,
Marek Vasut

2018-05-30 11:02:51

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

On 05/29/2018 09:55 AM, Lee Jones wrote:
> On Thu, 24 May 2018, Steve Twiss wrote:
>
>> Thanks Marek,
>>
>> On 23 May 2018 12:42 Marek Vasut wrote,
>>
>>> To: [email protected]
>>> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven <[email protected]>; Lee Jones <[email protected]>; Mark Brown <[email protected]>; Steve Twiss <[email protected]>; Wolfram Sang <[email protected]>; [email protected]
>>> Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
>>>
>>> The DA9063L does not contain RTC block, unlike the full DA9063.
>>> Do not allow binding RTC driver on this variant of the chip.
>>>
>>> Signed-off-by: Marek Vasut <[email protected]>
>>> Cc: Geert Uytterhoeven <[email protected]>
>>> Cc: Lee Jones <[email protected]>
>>> Cc: Mark Brown <[email protected]>
>>> Cc: Steve Twiss <[email protected]>
>>> Cc: Wolfram Sang <[email protected]>
>>> Cc: [email protected]
>>> ---
>>> drivers/mfd/da9063-core.c | 18 +++++++++++-------
>>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
>>> --- a/drivers/mfd/da9063-core.c
>>> +++ b/drivers/mfd/da9063-core.c
>>> @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
>>> .of_compatible = "dlg,da9063-onkey",
>>> },
>>> {
>>> + .name = DA9063_DRVNAME_VIBRATION,
>>> + },
>>> + { /* Only present on DA9063 , not on DA9063L */
>>> .name = DA9063_DRVNAME_RTC,
>>> .num_resources = ARRAY_SIZE(da9063_rtc_resources),
>>> .resources = da9063_rtc_resources,
>>> .of_compatible = "dlg,da9063-rtc",
>>> },
>>> - {
>>> - .name = DA9063_DRVNAME_VIBRATION,
>>> - },
>>> };
>>>
>>> static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq) {
>>> struct da9063_pdata *pdata = da9063->dev->platform_data;
>>> int model, variant_id, variant_code;
>>> - int ret;
>>> + int da9063_devs_len, ret;
>>>
>>> ret = da9063_clear_fault_log(da9063);
>>> if (ret < 0)
>>> @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
>>>
>>> da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
>>>
>>> - ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
>>> - ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
>>> - NULL);
>>> + da9063_devs_len = ARRAY_SIZE(da9063_devs);
>>> + /* RTC, the last device in the list, is only present on DA9063 */
>>> + if (da9063->type == PMIC_TYPE_DA9063L)
>>> + da9063_devs_len -= 1;
>>> +
>>> + ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
>>> + NULL, da9063->irq_base, NULL);
>>> if (ret)
>>> dev_err(da9063->dev, "Cannot add MFD cells\n");
>>>
>>
>> MFD cells definitely has less impact than regmap_range and regmap_irq.
>> I agree, there's no point in having a completely new
>> static const struct mfd_cell da9063l_devs[] = { ... } for DA9063L
>
> This solution is fragile.
>
> I agree that a new MFD cell is not required in its entirety. It
> would however, be better to split out the RTC entry into a new one and
> only register it when (da9063->type == PMIC_TYPE_DA9063). This is a
> better solution than messing around with passed struct sizes.

This indeed is better.

btw this da9063_device_init() function is missing a failpath to undo the
setup done by da9063_irq_init(), so I'll be sending a patch for that too
shortly.

--
Best regards,
Marek Vasut

2018-05-30 11:26:43

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 05/24/2018 07:30 PM, Steve Twiss wrote:
> On 24 May 2018 15:51 Marek Vasut wrote:
>
> Hi Marek,
>
>> To: Steve Twiss <[email protected]>; [email protected]
>> Cc: Marek Vasut <[email protected]>; Geert Uytterhoeven
>> <[email protected]>; Lee Jones <[email protected]>; Mark Brown
>> <[email protected]>; Wolfram Sang <[email protected]>;
>> [email protected]
>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>
>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>>>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>>>
>>>>> To: [email protected]
>>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>>
>>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>>>
>>>>
>>>> There's potentially more to this file. Without an RTC the regmap
>>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
>>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
>>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
>>>>
>>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>>>
>>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>>> {
>>>> .range_min = DA9063_REG_PAGE_CON,
>>>> .range_max = DA9063_REG_MON_A10_RES,
>>>> }, {
>>>> .range_min = DA9063_REG_SEQ,
>>>> .range_max = DA9063_REG_ID_32_31,
>>>> }, {
>>>> .range_min = DA9063_REG_SEQ_A,
>>>> .range_max = DA9063_REG_AUTO3_LOW,
>>>> }, {
>>>> .range_min = DA9063_REG_T_OFFSET,
>>>> .range_max = DA9063_BB_REG_GP_ID_19,
>>>> }, {
>>>> .range_min = DA9063_REG_CHIP_ID,
>>>> .range_max = DA9063_REG_CHIP_VARIANT,
>>>> },
>>>> };
>>>>
>>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>>>> {
>>>> .range_min = DA9063_REG_PAGE_CON,
>>>> .range_max = DA9063_REG_PAGE_CON,
>>>> }, {
>>>> .range_min = DA9063_REG_FAULT_LOG,
>>>> .range_max = DA9063_REG_VSYS_MON,
>>>> }, {
>>>> .range_min = DA9063_REG_SEQ,
>>>> .range_max = DA9063_REG_ID_32_31,
>>>> }, {
>>>> .range_min = DA9063_REG_SEQ_A,
>>>> .range_max = DA9063_REG_AUTO3_LOW,
>>>> }, {
>>>> .range_min = DA9063_REG_CONFIG_I,
>>>> .range_max = DA9063_BB_REG_MON_REG_4,
>>>> }, {
>>>> .range_min = DA9063_BB_REG_GP_ID_0,
>>>> .range_max = DA9063_BB_REG_GP_ID_19,
>>>> },
>>>> };
>>>>
>>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>>>> {
>>>> .range_min = DA9063_REG_PAGE_CON,
>>>> .range_max = DA9063_REG_EVENT_D,
>>>> }, {
>>>> .range_min = DA9063_REG_CONTROL_A,
>>>> .range_max = DA9063_REG_CONTROL_B,
>>>> }, {
>>>> .range_min = DA9063_REG_CONTROL_E,
>>>> .range_max = DA9063_REG_CONTROL_F,
>>>> }, {
>>>> .range_min = DA9063_REG_BCORE2_CONT,
>>>> .range_max = DA9063_REG_LDO11_CONT,
>>>> }, {
>>>> .range_min = DA9063_REG_DVC_1,
>>>> .range_max = DA9063_REG_ADC_MAN,
>>>> }, {
>>>> .range_min = DA9063_REG_ADC_RES_L,
>>>> .range_max = DA9063_REG_MON_A10_RES,
>>>> }, {
>>>> .range_min = DA9063_REG_SEQ,
>>>> .range_max = DA9063_REG_SEQ,
>>>> }, {
>>>> .range_min = DA9063_REG_EN_32K,
>>>> .range_max = DA9063_REG_EN_32K,
>>>> }, {
>>>> .range_min = DA9063_BB_REG_MON_REG_5,
>>>> .range_max = DA9063_BB_REG_MON_REG_6,
>>>> },
>>>> };
>>>>
>>>> However this is a larger and more wide-ranging change compared to the
>>>> one proposed by Marek, and would require other alterations to fit
>>>> this in. Also I'm undecided to what it would really add apart from a
>>>> new chip model: I have been told accessing the DA9063 RTC register locations
>>>> has no effect in the DA9063L.
>>>
>>> Looking at this further, there is also a new IRQ regmap.
>>> Again this comes down to whether a full chip model is needed or not.
>>> If not, then the IRQ map does not need to be changed as given. Otherwise the
>>> removal of the following:
>>>
>>> [DA9063_IRQ_ALARM] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_ALARM,
>>> },
>>> [DA9063_IRQ_TICK] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_TICK,
>>> },
>>>
>>> prior to registering the IRQs in the chip model would be needed.
>>> The new regmap_irq would be:
>>>
>>> static const struct regmap_irq da9063l_irqs[] = {
>>> /* DA9063 event A register */
>>> [DA9063L_IRQ_ONKEY] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_ONKEY,
>>> },
>>> [DA9063L_IRQ_ADC_RDY] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_ADC_RDY,
>>> },
>>> [DA9063L_IRQ_SEQ_RDY] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_SEQ_RDY,
>>> },
>>> /* DA9063 event B register */
>>> [DA9063L_IRQ_WAKE] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_WAKE,
>>> },
>>> [DA9063L_IRQ_TEMP] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_TEMP,
>>> },
>>> [DA9063L_IRQ_COMP_1V2] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_COMP_1V2,
>>> },
>>> [DA9063L_IRQ_LDO_LIM] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_LDO_LIM,
>>> },
>>> [DA9063L_IRQ_REG_UVOV] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_UVOV,
>>> },
>>> [DA9063L_IRQ_DVC_RDY] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_DVC_RDY,
>>> },
>>> [DA9063L_IRQ_VDD_MON] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_VDD_MON,
>>> },
>>> [DA9063L_IRQ_WARN] = {
>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> .mask = DA9063_M_VDD_WARN,
>>> },
>>> /* DA9063 event C register */
>>> [DA9063L_IRQ_GPI0] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI0,
>>> },
>>> [DA9063L_IRQ_GPI1] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI1,
>>> },
>>> [DA9063L_IRQ_GPI2] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI2,
>>> },
>>> [DA9063L_IRQ_GPI3] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI3,
>>> },
>>> [DA9063L_IRQ_GPI4] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI4,
>>> },
>>> [DA9063L_IRQ_GPI5] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI5,
>>> },
>>> [DA9063L_IRQ_GPI6] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI6,
>>> },
>>> [DA9063L_IRQ_GPI7] = {
>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> .mask = DA9063_M_GPI7,
>>> },
>>> /* DA9063 event D register */
>>> [DA9063L_IRQ_GPI8] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI8,
>>> },
>>> [DA9063L_IRQ_GPI9] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI9,
>>> },
>>> [DA9063L_IRQ_GPI10] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI10,
>>> },
>>> [DA9063L_IRQ_GPI11] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI11,
>>> },
>>> [DA9063L_IRQ_GPI12] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI12,
>>> },
>>> [DA9063L_IRQ_GPI13] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI13,
>>> },
>>> [DA9063L_IRQ_GPI14] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI14,
>>> },
>>> [DA9063L_IRQ_GPI15] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI15,
>>> },
>>> };
>>
>> We can probably do the same trick with the regmaps and irqmaps as with the
>> rest, that is, reorder them and register only a smaller portion ?
>
> I like the "reorder and only register a smaller portion" trick. But it wouldn't work
> with what I gave earlier today, without some modification.
> For instance, the first register readable entry range in the DA9063 BB is:
>
> static const struct regmap_range da9063_bb_readable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_BB_REG_SECOND_D,
> }, {
>
> But for the DA9063L, this first range entry would be changed, not removed:
>
> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> {
> .range_min = DA9063_REG_PAGE_CON,
> .range_max = DA9063_REG_MON_A10_RES,
> }, {
>
> So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
> into two pieces.
>
> However, it might get messy to maintain in future -- sometimes register ranges need to be
> updated with new components or if a new feature is added -- usually I need to work it
> all out on paper with the full register map. Splitting up ranges might make it a little
> messier. But, it's not impossible.
>
> For the DA9062 and DA9061 this was done using separate ranges and using the macro
> regmap_reg_range(). It's not that messy to read, e.g.
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367

Hum, can you point me to the datasheet sections so I can check this
difference please ? I think I have the rest of the feedback addressed,
so I want to check this one before submitting the next version.

--
Best regards,
Marek Vasut

2018-05-30 11:27:08

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 05/29/2018 09:46 AM, Lee Jones wrote:
> On Thu, 24 May 2018, Marek Vasut wrote:
>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>
> [...]
>
>>> static const struct regmap_irq da9063l_irqs[] = {
>>> /* DA9063 event A register */
>>> [DA9063L_IRQ_ONKEY] = {
>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> .mask = DA9063_M_ONKEY,
>>> },
>
> [...]
>
>>> [DA9063L_IRQ_GPI15] = {
>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> .mask = DA9063_M_GPI15,
>>> },
>>> };
>>
>> We can probably do the same trick with the regmaps and irqmaps as with
>> the rest, that is, reorder them and register only a smaller portion ?
>
> Please also consider using REGMAP_IRQ_REG().

Done in a new separate patch with a simple sed oneliner

sed -i "/\[DA9063_IRQ_/
{N;N;N;s/\n//g;s/.*\[\(DA9063_IRQ_[^]]\+\)].*reg_offset = \([^,]\+\),.*
= \([^,]\+\),.*/\tREGMAP_IRQ_REG(\1, \2, \3),/}" drivers/mfd/da9063-irq.c

--
Best regards,
Marek Vasut

2018-05-31 12:47:35

by Steve Twiss

[permalink] [raw]
Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 30 May 2018 12:25 Marek Vasut wrote:

> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
> On 05/24/2018 07:30 PM, Steve Twiss wrote:
> > On 24 May 2018 15:51 Marek Vasut wrote:
> >
> > Hi Marek,
> >
> >> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>
> >> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> >>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
> >>>>> On 23 May 2018 12:43 Marek Vasut wrote,
> >>>>>
> >>>>> To: [email protected]
> >>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>>>>
> >>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >>>>>
> >>>>
> >>>> There's potentially more to this file. Without an RTC the regmap
> >>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
> >>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> >>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
> >>>>
> >>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
> >>>>
> >>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> >>>> {
> >>>> .range_min = DA9063_REG_PAGE_CON,
> >>>> .range_max = DA9063_REG_MON_A10_RES,
> >>>> }, {
> >>>> .range_min = DA9063_REG_SEQ,
> >>>> .range_max = DA9063_REG_ID_32_31,
> >>>> }, {
> >>>> .range_min = DA9063_REG_SEQ_A,
> >>>> .range_max = DA9063_REG_AUTO3_LOW,
> >>>> }, {
> >>>> .range_min = DA9063_REG_T_OFFSET,
> >>>> .range_max = DA9063_BB_REG_GP_ID_19,
> >>>> }, {
> >>>> .range_min = DA9063_REG_CHIP_ID,
> >>>> .range_max = DA9063_REG_CHIP_VARIANT,
> >>>> },
> >>>> };
> >>>>
> >>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> >>>> {
> >>>> .range_min = DA9063_REG_PAGE_CON,
> >>>> .range_max = DA9063_REG_PAGE_CON,
> >>>> }, {
> >>>> .range_min = DA9063_REG_FAULT_LOG,
> >>>> .range_max = DA9063_REG_VSYS_MON,
> >>>> }, {
> >>>> .range_min = DA9063_REG_SEQ,
> >>>> .range_max = DA9063_REG_ID_32_31,
> >>>> }, {
> >>>> .range_min = DA9063_REG_SEQ_A,
> >>>> .range_max = DA9063_REG_AUTO3_LOW,
> >>>> }, {
> >>>> .range_min = DA9063_REG_CONFIG_I,
> >>>> .range_max = DA9063_BB_REG_MON_REG_4,
> >>>> }, {
> >>>> .range_min = DA9063_BB_REG_GP_ID_0,
> >>>> .range_max = DA9063_BB_REG_GP_ID_19,
> >>>> },
> >>>> };
> >>>>
> >>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> >>>> {
> >>>> .range_min = DA9063_REG_PAGE_CON,
> >>>> .range_max = DA9063_REG_EVENT_D,
> >>>> }, {
> >>>> .range_min = DA9063_REG_CONTROL_A,
> >>>> .range_max = DA9063_REG_CONTROL_B,
> >>>> }, {
> >>>> .range_min = DA9063_REG_CONTROL_E,
> >>>> .range_max = DA9063_REG_CONTROL_F,
> >>>> }, {
> >>>> .range_min = DA9063_REG_BCORE2_CONT,
> >>>> .range_max = DA9063_REG_LDO11_CONT,
> >>>> }, {
> >>>> .range_min = DA9063_REG_DVC_1,
> >>>> .range_max = DA9063_REG_ADC_MAN,
> >>>> }, {
> >>>> .range_min = DA9063_REG_ADC_RES_L,
> >>>> .range_max = DA9063_REG_MON_A10_RES,
> >>>> }, {
> >>>> .range_min = DA9063_REG_SEQ,
> >>>> .range_max = DA9063_REG_SEQ,
> >>>> }, {
> >>>> .range_min = DA9063_REG_EN_32K,
> >>>> .range_max = DA9063_REG_EN_32K,
> >>>> }, {
> >>>> .range_min = DA9063_BB_REG_MON_REG_5,
> >>>> .range_max = DA9063_BB_REG_MON_REG_6,
> >>>> },
> >>>> };
> >>>>
> >>>> However this is a larger and more wide-ranging change compared to the
> >>>> one proposed by Marek, and would require other alterations to fit
> >>>> this in. Also I'm undecided to what it would really add apart from a
> >>>> new chip model: I have been told accessing the DA9063 RTC register locations
> >>>> has no effect in the DA9063L.
> >>>
> >>> Looking at this further, there is also a new IRQ regmap.
> >>> Again this comes down to whether a full chip model is needed or not.
> >>> If not, then the IRQ map does not need to be changed as given. Otherwise the
> >>> removal of the following:
> >>>
> >>> [DA9063_IRQ_ALARM] = {
> >>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> .mask = DA9063_M_ALARM,
> >>> },
> >>> [DA9063_IRQ_TICK] = {
> >>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> .mask = DA9063_M_TICK,
> >>> },
> >>>
> >>> prior to registering the IRQs in the chip model would be needed.
> >>> The new regmap_irq would be:
> >>>
> >>> static const struct regmap_irq da9063l_irqs[] = {
> >>> /* DA9063 event A register */
> >>> [DA9063L_IRQ_ONKEY] = {
> >>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> .mask = DA9063_M_ONKEY,
> >>> },
> >>> [DA9063L_IRQ_ADC_RDY] = {
> >>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> .mask = DA9063_M_ADC_RDY,
> >>> },
> >>> [DA9063L_IRQ_SEQ_RDY] = {
> >>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> .mask = DA9063_M_SEQ_RDY,
> >>> },
> >>> /* DA9063 event B register */
> >>> [DA9063L_IRQ_WAKE] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_WAKE,
> >>> },
> >>> [DA9063L_IRQ_TEMP] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_TEMP,
> >>> },
> >>> [DA9063L_IRQ_COMP_1V2] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_COMP_1V2,
> >>> },
> >>> [DA9063L_IRQ_LDO_LIM] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_LDO_LIM,
> >>> },
> >>> [DA9063L_IRQ_REG_UVOV] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_UVOV,
> >>> },
> >>> [DA9063L_IRQ_DVC_RDY] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_DVC_RDY,
> >>> },
> >>> [DA9063L_IRQ_VDD_MON] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_VDD_MON,
> >>> },
> >>> [DA9063L_IRQ_WARN] = {
> >>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> .mask = DA9063_M_VDD_WARN,
> >>> },
> >>> /* DA9063 event C register */
> >>> [DA9063L_IRQ_GPI0] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI0,
> >>> },
> >>> [DA9063L_IRQ_GPI1] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI1,
> >>> },
> >>> [DA9063L_IRQ_GPI2] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI2,
> >>> },
> >>> [DA9063L_IRQ_GPI3] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI3,
> >>> },
> >>> [DA9063L_IRQ_GPI4] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI4,
> >>> },
> >>> [DA9063L_IRQ_GPI5] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI5,
> >>> },
> >>> [DA9063L_IRQ_GPI6] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI6,
> >>> },
> >>> [DA9063L_IRQ_GPI7] = {
> >>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> .mask = DA9063_M_GPI7,
> >>> },
> >>> /* DA9063 event D register */
> >>> [DA9063L_IRQ_GPI8] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI8,
> >>> },
> >>> [DA9063L_IRQ_GPI9] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI9,
> >>> },
> >>> [DA9063L_IRQ_GPI10] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI10,
> >>> },
> >>> [DA9063L_IRQ_GPI11] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI11,
> >>> },
> >>> [DA9063L_IRQ_GPI12] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI12,
> >>> },
> >>> [DA9063L_IRQ_GPI13] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI13,
> >>> },
> >>> [DA9063L_IRQ_GPI14] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI14,
> >>> },
> >>> [DA9063L_IRQ_GPI15] = {
> >>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> .mask = DA9063_M_GPI15,
> >>> },
> >>> };
> >>
> >> We can probably do the same trick with the regmaps and irqmaps as with the
> >> rest, that is, reorder them and register only a smaller portion ?
> >
> > I like the "reorder and only register a smaller portion" trick. But it wouldn't work
> > with what I gave earlier today, without some modification.
> > For instance, the first register readable entry range in the DA9063 BB is:
> >
> > static const struct regmap_range da9063_bb_readable_ranges[] = {
> > {
> > .range_min = DA9063_REG_PAGE_CON,
> > .range_max = DA9063_BB_REG_SECOND_D,
> > }, {
> >
> > But for the DA9063L, this first range entry would be changed, not removed:
> >
> > static const struct regmap_range da9063l_bb_readable_ranges[] = {
> > {
> > .range_min = DA9063_REG_PAGE_CON,
> > .range_max = DA9063_REG_MON_A10_RES,
> > }, {
> >
> > So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
> > into two pieces.
> >
> > However, it might get messy to maintain in future -- sometimes register ranges need to be
> > updated with new components or if a new feature is added -- usually I need to work it
> > all out on paper with the full register map. Splitting up ranges might make it a little
> > messier. But, it's not impossible.
> >
> > For the DA9062 and DA9061 this was done using separate ranges and using the macro
> > regmap_reg_range(). It's not that messy to read, e.g.
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367
>
> Hum, can you point me to the datasheet sections so I can check this
> difference please ? I think I have the rest of the feedback addressed,
> so I want to check this one before submitting the next version.

Hi Marek,

My apologies for the time taken to respond. I have been travelling.

Datasheets are found on the Dialog company website.
End of the page, look for Resources > Datasheets.

https://www.dialog-semiconductor.com/products/da9061
https://www.dialog-semiconductor.com/products/da9062
https://www.dialog-semiconductor.com/products/da9063
https://www.dialog-semiconductor.com/products/da9063L

The chip model {readable, writable, volatile} register definitions are given clearly in the device
drivers. At least they will match what is expected by the Linux device driver. There is no easy
chip model list found in the datasheets.

Regards,
Steve

2018-06-02 10:00:57

by Marek Vasut

[permalink] [raw]
Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

On 05/31/2018 02:45 PM, Steve Twiss wrote:
> On 30 May 2018 12:25 Marek Vasut wrote:
>
>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>> On 05/24/2018 07:30 PM, Steve Twiss wrote:
>>> On 24 May 2018 15:51 Marek Vasut wrote:
>>>
>>> Hi Marek,
>>>
>>>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>
>>>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>>>>>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>>>>>
>>>>>>> To: [email protected]
>>>>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>>>>
>>>>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>>>>>
>>>>>>
>>>>>> There's potentially more to this file. Without an RTC the regmap
>>>>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
>>>>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
>>>>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
>>>>>>
>>>>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>>>>> {
>>>>>> .range_min = DA9063_REG_PAGE_CON,
>>>>>> .range_max = DA9063_REG_MON_A10_RES,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_SEQ,
>>>>>> .range_max = DA9063_REG_ID_32_31,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_SEQ_A,
>>>>>> .range_max = DA9063_REG_AUTO3_LOW,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_T_OFFSET,
>>>>>> .range_max = DA9063_BB_REG_GP_ID_19,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_CHIP_ID,
>>>>>> .range_max = DA9063_REG_CHIP_VARIANT,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>>>>>> {
>>>>>> .range_min = DA9063_REG_PAGE_CON,
>>>>>> .range_max = DA9063_REG_PAGE_CON,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_FAULT_LOG,
>>>>>> .range_max = DA9063_REG_VSYS_MON,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_SEQ,
>>>>>> .range_max = DA9063_REG_ID_32_31,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_SEQ_A,
>>>>>> .range_max = DA9063_REG_AUTO3_LOW,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_CONFIG_I,
>>>>>> .range_max = DA9063_BB_REG_MON_REG_4,
>>>>>> }, {
>>>>>> .range_min = DA9063_BB_REG_GP_ID_0,
>>>>>> .range_max = DA9063_BB_REG_GP_ID_19,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>>>>>> {
>>>>>> .range_min = DA9063_REG_PAGE_CON,
>>>>>> .range_max = DA9063_REG_EVENT_D,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_CONTROL_A,
>>>>>> .range_max = DA9063_REG_CONTROL_B,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_CONTROL_E,
>>>>>> .range_max = DA9063_REG_CONTROL_F,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_BCORE2_CONT,
>>>>>> .range_max = DA9063_REG_LDO11_CONT,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_DVC_1,
>>>>>> .range_max = DA9063_REG_ADC_MAN,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_ADC_RES_L,
>>>>>> .range_max = DA9063_REG_MON_A10_RES,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_SEQ,
>>>>>> .range_max = DA9063_REG_SEQ,
>>>>>> }, {
>>>>>> .range_min = DA9063_REG_EN_32K,
>>>>>> .range_max = DA9063_REG_EN_32K,
>>>>>> }, {
>>>>>> .range_min = DA9063_BB_REG_MON_REG_5,
>>>>>> .range_max = DA9063_BB_REG_MON_REG_6,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>> However this is a larger and more wide-ranging change compared to the
>>>>>> one proposed by Marek, and would require other alterations to fit
>>>>>> this in. Also I'm undecided to what it would really add apart from a
>>>>>> new chip model: I have been told accessing the DA9063 RTC register locations
>>>>>> has no effect in the DA9063L.
>>>>>
>>>>> Looking at this further, there is also a new IRQ regmap.
>>>>> Again this comes down to whether a full chip model is needed or not.
>>>>> If not, then the IRQ map does not need to be changed as given. Otherwise the
>>>>> removal of the following:
>>>>>
>>>>> [DA9063_IRQ_ALARM] = {
>>>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> .mask = DA9063_M_ALARM,
>>>>> },
>>>>> [DA9063_IRQ_TICK] = {
>>>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> .mask = DA9063_M_TICK,
>>>>> },
>>>>>
>>>>> prior to registering the IRQs in the chip model would be needed.
>>>>> The new regmap_irq would be:
>>>>>
>>>>> static const struct regmap_irq da9063l_irqs[] = {
>>>>> /* DA9063 event A register */
>>>>> [DA9063L_IRQ_ONKEY] = {
>>>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> .mask = DA9063_M_ONKEY,
>>>>> },
>>>>> [DA9063L_IRQ_ADC_RDY] = {
>>>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> .mask = DA9063_M_ADC_RDY,
>>>>> },
>>>>> [DA9063L_IRQ_SEQ_RDY] = {
>>>>> .reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> .mask = DA9063_M_SEQ_RDY,
>>>>> },
>>>>> /* DA9063 event B register */
>>>>> [DA9063L_IRQ_WAKE] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_WAKE,
>>>>> },
>>>>> [DA9063L_IRQ_TEMP] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_TEMP,
>>>>> },
>>>>> [DA9063L_IRQ_COMP_1V2] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_COMP_1V2,
>>>>> },
>>>>> [DA9063L_IRQ_LDO_LIM] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_LDO_LIM,
>>>>> },
>>>>> [DA9063L_IRQ_REG_UVOV] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_UVOV,
>>>>> },
>>>>> [DA9063L_IRQ_DVC_RDY] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_DVC_RDY,
>>>>> },
>>>>> [DA9063L_IRQ_VDD_MON] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_VDD_MON,
>>>>> },
>>>>> [DA9063L_IRQ_WARN] = {
>>>>> .reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> .mask = DA9063_M_VDD_WARN,
>>>>> },
>>>>> /* DA9063 event C register */
>>>>> [DA9063L_IRQ_GPI0] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI0,
>>>>> },
>>>>> [DA9063L_IRQ_GPI1] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI1,
>>>>> },
>>>>> [DA9063L_IRQ_GPI2] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI2,
>>>>> },
>>>>> [DA9063L_IRQ_GPI3] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI3,
>>>>> },
>>>>> [DA9063L_IRQ_GPI4] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI4,
>>>>> },
>>>>> [DA9063L_IRQ_GPI5] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI5,
>>>>> },
>>>>> [DA9063L_IRQ_GPI6] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI6,
>>>>> },
>>>>> [DA9063L_IRQ_GPI7] = {
>>>>> .reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> .mask = DA9063_M_GPI7,
>>>>> },
>>>>> /* DA9063 event D register */
>>>>> [DA9063L_IRQ_GPI8] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI8,
>>>>> },
>>>>> [DA9063L_IRQ_GPI9] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI9,
>>>>> },
>>>>> [DA9063L_IRQ_GPI10] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI10,
>>>>> },
>>>>> [DA9063L_IRQ_GPI11] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI11,
>>>>> },
>>>>> [DA9063L_IRQ_GPI12] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI12,
>>>>> },
>>>>> [DA9063L_IRQ_GPI13] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI13,
>>>>> },
>>>>> [DA9063L_IRQ_GPI14] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI14,
>>>>> },
>>>>> [DA9063L_IRQ_GPI15] = {
>>>>> .reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> .mask = DA9063_M_GPI15,
>>>>> },
>>>>> };
>>>>
>>>> We can probably do the same trick with the regmaps and irqmaps as with the
>>>> rest, that is, reorder them and register only a smaller portion ?
>>>
>>> I like the "reorder and only register a smaller portion" trick. But it wouldn't work
>>> with what I gave earlier today, without some modification.
>>> For instance, the first register readable entry range in the DA9063 BB is:
>>>
>>> static const struct regmap_range da9063_bb_readable_ranges[] = {
>>> {
>>> .range_min = DA9063_REG_PAGE_CON,
>>> .range_max = DA9063_BB_REG_SECOND_D,
>>> }, {
>>>
>>> But for the DA9063L, this first range entry would be changed, not removed:
>>>
>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>> {
>>> .range_min = DA9063_REG_PAGE_CON,
>>> .range_max = DA9063_REG_MON_A10_RES,
>>> }, {
>>>
>>> So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
>>> into two pieces.
>>>
>>> However, it might get messy to maintain in future -- sometimes register ranges need to be
>>> updated with new components or if a new feature is added -- usually I need to work it
>>> all out on paper with the full register map. Splitting up ranges might make it a little
>>> messier. But, it's not impossible.
>>>
>>> For the DA9062 and DA9061 this was done using separate ranges and using the macro
>>> regmap_reg_range(). It's not that messy to read, e.g.
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367
>>
>> Hum, can you point me to the datasheet sections so I can check this
>> difference please ? I think I have the rest of the feedback addressed,
>> so I want to check this one before submitting the next version.
>
> Hi Marek,

Hi,

> My apologies for the time taken to respond. I have been travelling.

No worries

> Datasheets are found on the Dialog company website.
> End of the page, look for Resources > Datasheets.
>
> https://www.dialog-semiconductor.com/products/da9061
> https://www.dialog-semiconductor.com/products/da9062
> https://www.dialog-semiconductor.com/products/da9063
> https://www.dialog-semiconductor.com/products/da9063L

I found those, but they even list the RTC block in the register list .

> The chip model {readable, writable, volatile} register definitions are given clearly in the device
> drivers. At least they will match what is expected by the Linux device driver. There is no easy
> chip model list found in the datasheets.

Well, let me resend what I have and let's see where this gets us.

--
Best regards,
Marek Vasut