* [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
@ 2018-05-23 11:42 ` Marek Vasut
2018-05-23 11:50 ` Mark Brown
` (3 more replies)
2018-05-23 11:42 ` [PATCH 3/6] mfd: da9063: Add DA9063L type Marek Vasut
` (6 subsequent siblings)
7 siblings, 4 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 11:42 UTC (permalink / raw)
To: linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
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 <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
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
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
@ 2018-05-23 11:50 ` Mark Brown
2018-05-23 11:55 ` Geert Uytterhoeven
` (2 subsequent siblings)
3 siblings, 0 replies; 36+ messages in thread
From: Mark Brown @ 2018-05-23 11:50 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-kernel, Marek Vasut, Geert Uytterhoeven, Lee Jones,
Steve Twiss, Wolfram Sang, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 304 bytes --]
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 <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
2018-05-23 11:50 ` Mark Brown
@ 2018-05-23 11:55 ` Geert Uytterhoeven
2018-05-23 12:15 ` Marek Vasut
2018-05-26 9:16 ` kbuild test robot
2018-05-26 11:01 ` kbuild test robot
3 siblings, 1 reply; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 11:55 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- 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 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:55 ` Geert Uytterhoeven
@ 2018-05-23 12:15 ` Marek Vasut
0 siblings, 0 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 12:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On 05/23/2018 01:55 PM, Geert Uytterhoeven wrote:
> On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
>> --- 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
2018-05-23 11:50 ` Mark Brown
2018-05-23 11:55 ` Geert Uytterhoeven
@ 2018-05-26 9:16 ` kbuild test robot
2018-05-26 9:58 ` Marek Vasut
2018-05-26 11:01 ` kbuild test robot
3 siblings, 1 reply; 36+ messages in thread
From: kbuild test robot @ 2018-05-26 9:16 UTC (permalink / raw)
To: Marek Vasut
Cc: kbuild-all, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang,
linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 8343 bytes --]
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 = ®ulators->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, ®l->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
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29666 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-26 9:16 ` kbuild test robot
@ 2018-05-26 9:58 ` Marek Vasut
2018-05-30 5:21 ` Ye Xiaolong
0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2018-05-26 9:58 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang,
linux-renesas-soc
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-26 9:58 ` Marek Vasut
@ 2018-05-30 5:21 ` Ye Xiaolong
2018-05-30 10:45 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Ye Xiaolong @ 2018-05-30 5:21 UTC (permalink / raw)
To: Marek Vasut
Cc: kbuild test robot, kbuild-all, linux-kernel, Marek Vasut,
Geert Uytterhoeven, Lee Jones, Mark Brown, Steve Twiss,
Wolfram Sang, linux-renesas-soc
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
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-30 5:21 ` Ye Xiaolong
@ 2018-05-30 10:45 ` Marek Vasut
0 siblings, 0 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-30 10:45 UTC (permalink / raw)
To: Ye Xiaolong
Cc: kbuild test robot, kbuild-all, linux-kernel, Marek Vasut,
Geert Uytterhoeven, Lee Jones, Mark Brown, Steve Twiss,
Wolfram Sang, linux-renesas-soc
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/6] mfd: da9063: Replace model with type
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
` (2 preceding siblings ...)
2018-05-26 9:16 ` kbuild test robot
@ 2018-05-26 11:01 ` kbuild test robot
3 siblings, 0 replies; 36+ messages in thread
From: kbuild test robot @ 2018-05-26 11:01 UTC (permalink / raw)
To: Marek Vasut
Cc: kbuild-all, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang,
linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]
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 = ®ulators->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, ®l->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
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32915 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 3/6] mfd: da9063: Add DA9063L type
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
@ 2018-05-23 11:42 ` Marek Vasut
2018-05-23 12:00 ` Geert Uytterhoeven
2018-05-24 13:06 ` Steve Twiss
2018-05-23 11:42 ` [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L Marek Vasut
` (5 subsequent siblings)
7 siblings, 2 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 11:42 UTC (permalink / raw)
To: linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
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
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 3/6] mfd: da9063: Add DA9063L type
2018-05-23 11:42 ` [PATCH 3/6] mfd: da9063: Add DA9063L type Marek Vasut
@ 2018-05-23 12:00 ` Geert Uytterhoeven
2018-05-24 13:06 ` Steve Twiss
1 sibling, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 12:00 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 3/6] mfd: da9063: Add DA9063L type
2018-05-23 11:42 ` [PATCH 3/6] mfd: da9063: Add DA9063L type Marek Vasut
2018-05-23 12:00 ` Geert Uytterhoeven
@ 2018-05-24 13:06 ` Steve Twiss
1 sibling, 0 replies; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 13:06 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
On 23 May 2018 12:42 Marek Vasut wrote:
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> 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 <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> 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 <stwiss.opensource@diasemi.com>
Regards,
Steve
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
2018-05-23 11:42 ` [PATCH 2/6] mfd: da9063: Replace model with type Marek Vasut
2018-05-23 11:42 ` [PATCH 3/6] mfd: da9063: Add DA9063L type Marek Vasut
@ 2018-05-23 11:42 ` Marek Vasut
2018-05-23 12:00 ` Geert Uytterhoeven
2018-05-24 12:50 ` Steve Twiss
2018-05-23 11:42 ` [PATCH 5/6] mfd: da9063: Handle less LDOs " Marek Vasut
` (4 subsequent siblings)
7 siblings, 2 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 11:42 UTC (permalink / raw)
To: linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
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 <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
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
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
2018-05-23 11:42 ` [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L Marek Vasut
@ 2018-05-23 12:00 ` Geert Uytterhoeven
2018-05-24 12:50 ` Steve Twiss
1 sibling, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 12:00 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
2018-05-23 11:42 ` [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L Marek Vasut
2018-05-23 12:00 ` Geert Uytterhoeven
@ 2018-05-24 12:50 ` Steve Twiss
2018-05-29 7:55 ` Lee Jones
1 sibling, 1 reply; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 12:50 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Thanks Marek,
On 23 May 2018 12:42 Marek Vasut wrote,
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> 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 <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> 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 <stwiss.opensource@diasemi.com>
Regards,
Steve
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
2018-05-24 12:50 ` Steve Twiss
@ 2018-05-29 7:55 ` Lee Jones
2018-05-30 10:59 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Lee Jones @ 2018-05-29 7:55 UTC (permalink / raw)
To: Steve Twiss
Cc: Marek Vasut, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Mark Brown, Wolfram Sang, linux-renesas-soc
On Thu, 24 May 2018, Steve Twiss wrote:
> Thanks Marek,
>
> On 23 May 2018 12:42 Marek Vasut wrote,
>
> > To: linux-kernel@vger.kernel.org
> > Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> > 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 <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> > 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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
2018-05-29 7:55 ` Lee Jones
@ 2018-05-30 10:59 ` Marek Vasut
0 siblings, 0 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-30 10:59 UTC (permalink / raw)
To: Lee Jones, Steve Twiss
Cc: linux-kernel, Marek Vasut, Geert Uytterhoeven, Mark Brown,
Wolfram Sang, linux-renesas-soc
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: linux-kernel@vger.kernel.org
>>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>>> 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 <marek.vasut+renesas@gmail.com>
>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Cc: Lee Jones <lee.jones@linaro.org>
>>> Cc: Mark Brown <broonie@kernel.org>
>>> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
>>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>> Cc: linux-renesas-soc@vger.kernel.org
>>> ---
>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
` (2 preceding siblings ...)
2018-05-23 11:42 ` [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L Marek Vasut
@ 2018-05-23 11:42 ` Marek Vasut
2018-05-23 11:50 ` Mark Brown
2018-05-23 12:05 ` Geert Uytterhoeven
2018-05-23 11:42 ` [PATCH 6/6] mfd: da9063: Add DA9063L support Marek Vasut
` (3 subsequent siblings)
7 siblings, 2 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 11:42 UTC (permalink / raw)
To: linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
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 <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
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
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L
2018-05-23 11:42 ` [PATCH 5/6] mfd: da9063: Handle less LDOs " Marek Vasut
@ 2018-05-23 11:50 ` Mark Brown
2018-05-23 12:05 ` Geert Uytterhoeven
1 sibling, 0 replies; 36+ messages in thread
From: Mark Brown @ 2018-05-23 11:50 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-kernel, Marek Vasut, Geert Uytterhoeven, Lee Jones,
Steve Twiss, Wolfram Sang, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
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 <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L
2018-05-23 11:42 ` [PATCH 5/6] mfd: da9063: Handle less LDOs " Marek Vasut
2018-05-23 11:50 ` Mark Brown
@ 2018-05-23 12:05 ` Geert Uytterhoeven
1 sibling, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 12:05 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
` (3 preceding siblings ...)
2018-05-23 11:42 ` [PATCH 5/6] mfd: da9063: Handle less LDOs " Marek Vasut
@ 2018-05-23 11:42 ` Marek Vasut
2018-05-23 11:50 ` Mark Brown
` (2 more replies)
2018-05-23 11:49 ` [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Mark Brown
` (2 subsequent siblings)
7 siblings, 3 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-23 11:42 UTC (permalink / raw)
To: linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
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
^ permalink raw reply related [flat|nested] 36+ messages in thread* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-23 11:42 ` [PATCH 6/6] mfd: da9063: Add DA9063L support Marek Vasut
@ 2018-05-23 11:50 ` Mark Brown
2018-05-23 12:06 ` Geert Uytterhoeven
2018-05-24 11:48 ` Steve Twiss
2 siblings, 0 replies; 36+ messages in thread
From: Mark Brown @ 2018-05-23 11:50 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-kernel, Marek Vasut, Geert Uytterhoeven, Lee Jones,
Steve Twiss, Wolfram Sang, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 212 bytes --]
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 <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-23 11:42 ` [PATCH 6/6] mfd: da9063: Add DA9063L support Marek Vasut
2018-05-23 11:50 ` Mark Brown
@ 2018-05-23 12:06 ` Geert Uytterhoeven
2018-05-24 11:48 ` Steve Twiss
2 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 12:06 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-23 11:42 ` [PATCH 6/6] mfd: da9063: Add DA9063L support Marek Vasut
2018-05-23 11:50 ` Mark Brown
2018-05-23 12:06 ` Geert Uytterhoeven
@ 2018-05-24 11:48 ` Steve Twiss
2018-05-24 12:32 ` Steve Twiss
2 siblings, 1 reply; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 11:48 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Thanks Marek,
> On 23 May 2018 12:43 Marek Vasut wrote,
>
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>;
> Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>;
> Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> 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 <stwiss.opensource@diasemi.com>
Regards,
Steve
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> 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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-24 11:48 ` Steve Twiss
@ 2018-05-24 12:32 ` Steve Twiss
2018-05-24 14:50 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 12:32 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, linux-renesas-soc
Hi Marek,
On 24 May 2018 @ 12:49 Steve Twiss wrote:
> To: Marek Vasut <marek.vasut@gmail.com>; linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Thanks Marek,
>
> > On 23 May 2018 12:43 Marek Vasut wrote,
> >
> > To: linux-kernel@vger.kernel.org
> > Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>;
> > Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> > 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 <stwiss.opensource@diasemi.com>
>
> Regards,
> Steve
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> > 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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-24 12:32 ` Steve Twiss
@ 2018-05-24 14:50 ` Marek Vasut
2018-05-24 17:30 ` Steve Twiss
2018-05-29 7:46 ` Lee Jones
0 siblings, 2 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-24 14:50 UTC (permalink / raw)
To: Steve Twiss, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, linux-renesas-soc
On 05/24/2018 02:32 PM, Steve Twiss wrote:
> Hi Marek,
>
> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>
>> To: Marek Vasut <marek.vasut@gmail.com>; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>
>> Thanks Marek,
>>
>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>
>>> To: linux-kernel@vger.kernel.org
>>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>;
>>> Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-24 14:50 ` Marek Vasut
@ 2018-05-24 17:30 ` Steve Twiss
2018-05-30 11:24 ` Marek Vasut
2018-05-29 7:46 ` Lee Jones
1 sibling, 1 reply; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 17:30 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, linux-renesas-soc
On 24 May 2018 15:51 Marek Vasut wrote:
Hi Marek,
> To: Steve Twiss <stwiss.opensource@diasemi.com>; linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown
> <broonie@kernel.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>;
> linux-renesas-soc@vger.kernel.org
> 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: linux-kernel@vger.kernel.org
> >>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-24 17:30 ` Steve Twiss
@ 2018-05-30 11:24 ` Marek Vasut
2018-05-31 12:45 ` Steve Twiss
0 siblings, 1 reply; 36+ messages in thread
From: Marek Vasut @ 2018-05-30 11:24 UTC (permalink / raw)
To: Steve Twiss, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, linux-renesas-soc
On 05/24/2018 07:30 PM, Steve Twiss wrote:
> On 24 May 2018 15:51 Marek Vasut wrote:
>
> Hi Marek,
>
>> To: Steve Twiss <stwiss.opensource@diasemi.com>; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven
>> <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown
>> <broonie@kernel.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>;
>> linux-renesas-soc@vger.kernel.org
>> 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: linux-kernel@vger.kernel.org
>>>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-30 11:24 ` Marek Vasut
@ 2018-05-31 12:45 ` Steve Twiss
2018-06-02 9:59 ` Marek Vasut
0 siblings, 1 reply; 36+ messages in thread
From: Steve Twiss @ 2018-05-31 12:45 UTC (permalink / raw)
To: Marek Vasut, LKML
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, LINUX RENESAS SOC
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: linux-kernel@vger.kernel.org
> >>>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-31 12:45 ` Steve Twiss
@ 2018-06-02 9:59 ` Marek Vasut
0 siblings, 0 replies; 36+ messages in thread
From: Marek Vasut @ 2018-06-02 9:59 UTC (permalink / raw)
To: Steve Twiss, LKML
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Wolfram Sang, LINUX RENESAS SOC
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: linux-kernel@vger.kernel.org
>>>>>>> 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-24 14:50 ` Marek Vasut
2018-05-24 17:30 ` Steve Twiss
@ 2018-05-29 7:46 ` Lee Jones
2018-05-30 11:26 ` Marek Vasut
1 sibling, 1 reply; 36+ messages in thread
From: Lee Jones @ 2018-05-29 7:46 UTC (permalink / raw)
To: Marek Vasut
Cc: Steve Twiss, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Mark Brown, Wolfram Sang, linux-renesas-soc
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
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
2018-05-29 7:46 ` Lee Jones
@ 2018-05-30 11:26 ` Marek Vasut
0 siblings, 0 replies; 36+ messages in thread
From: Marek Vasut @ 2018-05-30 11:26 UTC (permalink / raw)
To: Lee Jones
Cc: Steve Twiss, linux-kernel, Marek Vasut, Geert Uytterhoeven,
Mark Brown, Wolfram Sang, linux-renesas-soc
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
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
` (4 preceding siblings ...)
2018-05-23 11:42 ` [PATCH 6/6] mfd: da9063: Add DA9063L support Marek Vasut
@ 2018-05-23 11:49 ` Mark Brown
2018-05-23 11:53 ` Geert Uytterhoeven
2018-05-24 12:03 ` Steve Twiss
7 siblings, 0 replies; 36+ messages in thread
From: Mark Brown @ 2018-05-23 11:49 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-kernel, Marek Vasut, Geert Uytterhoeven, Lee Jones,
Steve Twiss, Wolfram Sang, linux-renesas-soc
[-- Attachment #1: Type: text/plain, Size: 313 bytes --]
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 <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
` (5 preceding siblings ...)
2018-05-23 11:49 ` [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Mark Brown
@ 2018-05-23 11:53 ` Geert Uytterhoeven
2018-05-24 12:03 ` Steve Twiss
7 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2018-05-23 11:53 UTC (permalink / raw)
To: Marek Vasut
Cc: Linux Kernel Mailing List, Marek Vasut, Geert Uytterhoeven,
Lee Jones, Mark Brown, Steve Twiss, Wolfram Sang, Linux-Renesas
On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> 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 <marek.vasut+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 36+ messages in thread* RE: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
2018-05-23 11:42 [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063 Marek Vasut
` (6 preceding siblings ...)
2018-05-23 11:53 ` Geert Uytterhoeven
@ 2018-05-24 12:03 ` Steve Twiss
7 siblings, 0 replies; 36+ messages in thread
From: Steve Twiss @ 2018-05-24 12:03 UTC (permalink / raw)
To: Marek Vasut, linux-kernel
Cc: Marek Vasut, Geert Uytterhoeven, Lee Jones, Mark Brown,
Steve Twiss, Wolfram Sang, linux-renesas-soc
Hi Marek,
On 23 May 2018 12:42 Marek Vasut wrote:
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> 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 <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> 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 <stwiss.opensource@diasemi.com>
Regards,
Steve
^ permalink raw reply [flat|nested] 36+ messages in thread