* [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions @ 2014-11-04 13:33 Ivan T. Ivanov 2014-11-04 14:56 ` Fabio Estevam ` (3 more replies) 0 siblings, 4 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-04 13:33 UTC (permalink / raw) To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala Cc: Ivan T. Ivanov, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree, linux-kernel, linux-arm-msm Update compatible string with runtime detected chip revision information, for example qcom,pm8941 will become qcom,pm8941-v1.0. Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com> --- .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 18 ++- drivers/mfd/qcom-spmi-pmic.c | 142 +++++++++++++++++++++ 2 files changed, 156 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 7182b88..bbe7db8 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -15,10 +15,20 @@ each. A function can consume one or more of these fixed-size register regions. Required properties: - compatible: Should contain one of: - "qcom,pm8941" - "qcom,pm8841" - "qcom,pma8084" - or generalized "qcom,spmi-pmic". + qcom,pm8941, + qcom,pm8841, + qcom,pm8019, + qcom,pm8226, + qcom,pm8110, + qcom,pma8084, + qcom,pmi8962, + qcom,pmd9635, + qcom,pm8994, + qcom,pmi8994, + qcom,pm8916, + qcom,pm8004, + qcom,pm8909, + or generalized "qcom,spmi-pmic". - reg: Specifies the SPMI USID slave address for this device. For more information see: Documentation/devicetree/bindings/spmi/spmi.txt diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c index 4b8beb2..67446a4 100644 --- a/drivers/mfd/qcom-spmi-pmic.c +++ b/drivers/mfd/qcom-spmi-pmic.c @@ -13,10 +13,126 @@ #include <linux/kernel.h> #include <linux/module.h> +#include <linux/slab.h> #include <linux/spmi.h> #include <linux/regmap.h> +#include <linux/of.h> #include <linux/of_platform.h> +#define PMIC_REV2 0x101 +#define PMIC_REV3 0x102 +#define PMIC_REV4 0x103 +#define PMIC_TYPE 0x104 +#define PMIC_SUBTYPE 0x105 + +#define PMIC_TYPE_VALUE 0x51 + +#define PM8941_SUBTYPE 0x01 +#define PM8841_SUBTYPE 0x02 +#define PM8019_SUBTYPE 0x03 +#define PM8226_SUBTYPE 0x04 +#define PM8110_SUBTYPE 0x05 +#define PMA8084_SUBTYPE 0x06 +#define PMI8962_SUBTYPE 0x07 +#define PMD9635_SUBTYPE 0x08 +#define PM8994_SUBTYPE 0x09 +#define PMI8994_SUBTYPE 0x0a +#define PM8916_SUBTYPE 0x0b +#define PM8004_SUBTYPE 0x0c +#define PM8909_SUBTYPE 0x0d + +static int pmic_spmi_read_revid(struct regmap *map, char **name, + int *major, int *minor) +{ + unsigned int rev2, rev3, rev4, type, subtype; + int ret; + + ret = regmap_read(map, PMIC_TYPE, &type); + if (ret < 0) + return ret; + + if (type != PMIC_TYPE_VALUE) + return -EINVAL; + + ret = regmap_read(map, PMIC_SUBTYPE, &subtype); + if (ret < 0) + return ret; + + rev2 = regmap_read(map, PMIC_REV2, &rev2); + if (ret < 0) + return ret; + + rev3 = regmap_read(map, PMIC_REV3, &rev3); + if (ret < 0) + return ret; + + rev4 = regmap_read(map, PMIC_REV4, &rev4); + if (ret < 0) + return ret; + + /* + * In early versions of PM8941 and PM8226, the major revision number + * started incrementing from 0 (eg 0 = v1.0, 1 = v2.0). + * Increment the major revision number here if the chip is an early + * version of PM8941 or PM8226. + */ + if ((subtype == PM8941_SUBTYPE || subtype == PM8226_SUBTYPE) && + rev4 < 0x02) + rev4++; + + *major = rev4; + if (subtype == PM8110_SUBTYPE) + *minor = rev2; + else + *minor = rev3; + + switch (subtype) { + case PM8941_SUBTYPE: + *name = "pm8941"; + break; + case PM8841_SUBTYPE: + *name = "pm8841"; + break; + case PM8019_SUBTYPE: + *name = "pm8019"; + break; + case PM8226_SUBTYPE: + *name = "pm8226"; + break; + case PM8110_SUBTYPE: + *name = "pm8110"; + break; + case PMA8084_SUBTYPE: + *name = "pma8084"; + break; + case PMI8962_SUBTYPE: + *name = "pmi8962"; + break; + case PMD9635_SUBTYPE: + *name = "pmd8635"; + break; + case PM8994_SUBTYPE: + *name = "pm8994"; + break; + case PMI8994_SUBTYPE: + *name = "pmi8994"; + break; + case PM8916_SUBTYPE: + *name = "pm8916"; + break; + case PM8004_SUBTYPE: + *name = "pm8004"; + break; + case PM8909_SUBTYPE: + *name = "pm8909"; + break; + default: + return -EINVAL; + } + + return 0; +} + static const struct regmap_config spmi_regmap_config = { .reg_bits = 16, .val_bits = 8, @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device *sdev) { struct device_node *root = sdev->dev.of_node; struct regmap *regmap; + struct property *prop; + int major, minor, ret; + char *name, compatible[32]; regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config); if (IS_ERR(regmap)) return PTR_ERR(regmap); + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); + if (!ret) { + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", + name, major, minor); + prop = kzalloc(sizeof(*prop), GFP_KERNEL); + if (prop) { + prop->name = kstrdup("compatible", GFP_KERNEL); + prop->value = kstrdup(compatible, GFP_KERNEL); + prop->length = strlen(prop->value); + of_update_property(root, prop); + } + } + return of_platform_populate(root, NULL, NULL, &sdev->dev); } @@ -45,7 +177,17 @@ static const struct of_device_id pmic_spmi_id_table[] = { { .compatible = "qcom,spmi-pmic" }, { .compatible = "qcom,pm8941" }, { .compatible = "qcom,pm8841" }, + { .compatible = "qcom,pm8019" }, + { .compatible = "qcom,pm8226" }, + { .compatible = "qcom,pm8110" }, { .compatible = "qcom,pma8084" }, + { .compatible = "qcom,pmi8962" }, + { .compatible = "qcom,pmd9635" }, + { .compatible = "qcom,pm8994" }, + { .compatible = "qcom,pmi8994" }, + { .compatible = "qcom,pm8916" }, + { .compatible = "qcom,pm8004" }, + { .compatible = "qcom,pm8909" }, { } }; MODULE_DEVICE_TABLE(of, pmic_spmi_id_table); -- 1.9.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 13:33 [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions Ivan T. Ivanov @ 2014-11-04 14:56 ` Fabio Estevam 2014-11-04 15:17 ` Ivan T. Ivanov [not found] ` <1415108003-16387-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> ` (2 subsequent siblings) 3 siblings, 1 reply; 20+ messages in thread From: Fabio Estevam @ 2014-11-04 14:56 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel, linux-arm-msm On Tue, Nov 4, 2014 at 11:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > + ret = regmap_read(map, PMIC_SUBTYPE, &subtype); > + if (ret < 0) > + return ret; > + > + rev2 = regmap_read(map, PMIC_REV2, &rev2); > + if (ret < 0) > + return ret; I think you meant: ret = regmap_read(map, PMIC_REV2, &rev2); > + > + rev3 = regmap_read(map, PMIC_REV3, &rev3); Likewise. > + if (ret < 0) > + return ret; > + > + rev4 = regmap_read(map, PMIC_REV4, &rev4); Likewise. > + if (ret < 0) > + return ret; ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 14:56 ` Fabio Estevam @ 2014-11-04 15:17 ` Ivan T. Ivanov 0 siblings, 0 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-04 15:17 UTC (permalink / raw) To: Fabio Estevam Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel, linux-arm-msm On Tue, 2014-11-04 at 12:56 -0200, Fabio Estevam wrote: > On Tue, Nov 4, 2014 at 11:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > > + ret = regmap_read(map, PMIC_SUBTYPE, &subtype); > > + if (ret < 0) > > + return ret; > > + > > + rev2 = regmap_read(map, PMIC_REV2, &rev2); > > + if (ret < 0) > > + return ret; > > I think you meant: > ret = regmap_read(map, PMIC_REV2, &rev2); > > > + > > + rev3 = regmap_read(map, PMIC_REV3, &rev3); > > Likewise. > > > + if (ret < 0) > > + return ret; > > + > > + rev4 = regmap_read(map, PMIC_REV4, &rev4); > > Likewise. > > > True. Will fix. Thank you. Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <1415108003-16387-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions [not found] ` <1415108003-16387-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> @ 2014-11-04 15:06 ` Stanimir Varbanov 2014-11-04 15:22 ` Ivan T. Ivanov 0 siblings, 1 reply; 20+ messages in thread From: Stanimir Varbanov @ 2014-11-04 15:06 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA Hi Ivan, Thanks for the patch! On 11/04/2014 03:33 PM, Ivan T. Ivanov wrote: > Update compatible string with runtime detected chip revision > information, for example qcom,pm8941 will become qcom,pm8941-v1.0. > > Signed-off-by: Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> > --- > .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 18 ++- > drivers/mfd/qcom-spmi-pmic.c | 142 +++++++++++++++++++++ > 2 files changed, 156 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > index 7182b88..bbe7db8 100644 > --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > @@ -15,10 +15,20 @@ each. A function can consume one or more of these fixed-size register regions. > > Required properties: > - compatible: Should contain one of: > - "qcom,pm8941" > - "qcom,pm8841" > - "qcom,pma8084" > - or generalized "qcom,spmi-pmic". > + qcom,pm8941, > + qcom,pm8841, > + qcom,pm8019, > + qcom,pm8226, > + qcom,pm8110, > + qcom,pma8084, > + qcom,pmi8962, > + qcom,pmd9635, > + qcom,pm8994, > + qcom,pmi8994, > + qcom,pm8916, > + qcom,pm8004, > + qcom,pm8909, > + or generalized "qcom,spmi-pmic". > - reg: Specifies the SPMI USID slave address for this device. > For more information see: > Documentation/devicetree/bindings/spmi/spmi.txt > diff --git a/drivers/mfd/qcom-spmi-pmic.c b/drivers/mfd/qcom-spmi-pmic.c > index 4b8beb2..67446a4 100644 > --- a/drivers/mfd/qcom-spmi-pmic.c > +++ b/drivers/mfd/qcom-spmi-pmic.c > @@ -13,10 +13,126 @@ > > #include <linux/kernel.h> > #include <linux/module.h> > +#include <linux/slab.h> > #include <linux/spmi.h> > #include <linux/regmap.h> > +#include <linux/of.h> > #include <linux/of_platform.h> > > +#define PMIC_REV2 0x101 > +#define PMIC_REV3 0x102 > +#define PMIC_REV4 0x103 > +#define PMIC_TYPE 0x104 > +#define PMIC_SUBTYPE 0x105 > + > +#define PMIC_TYPE_VALUE 0x51 > + > +#define PM8941_SUBTYPE 0x01 > +#define PM8841_SUBTYPE 0x02 > +#define PM8019_SUBTYPE 0x03 > +#define PM8226_SUBTYPE 0x04 > +#define PM8110_SUBTYPE 0x05 > +#define PMA8084_SUBTYPE 0x06 > +#define PMI8962_SUBTYPE 0x07 > +#define PMD9635_SUBTYPE 0x08 > +#define PM8994_SUBTYPE 0x09 > +#define PMI8994_SUBTYPE 0x0a > +#define PM8916_SUBTYPE 0x0b > +#define PM8004_SUBTYPE 0x0c > +#define PM8909_SUBTYPE 0x0d > + > +static int pmic_spmi_read_revid(struct regmap *map, char **name, > + int *major, int *minor) > +{ > + unsigned int rev2, rev3, rev4, type, subtype; > + int ret; > + > + ret = regmap_read(map, PMIC_TYPE, &type); > + if (ret < 0) > + return ret; > + > + if (type != PMIC_TYPE_VALUE) > + return -EINVAL; > + > + ret = regmap_read(map, PMIC_SUBTYPE, &subtype); > + if (ret < 0) > + return ret; > + > + rev2 = regmap_read(map, PMIC_REV2, &rev2); > + if (ret < 0) > + return ret; > + > + rev3 = regmap_read(map, PMIC_REV3, &rev3); > + if (ret < 0) > + return ret; > + > + rev4 = regmap_read(map, PMIC_REV4, &rev4); > + if (ret < 0) > + return ret; > + > + /* > + * In early versions of PM8941 and PM8226, the major revision number > + * started incrementing from 0 (eg 0 = v1.0, 1 = v2.0). > + * Increment the major revision number here if the chip is an early > + * version of PM8941 or PM8226. > + */ > + if ((subtype == PM8941_SUBTYPE || subtype == PM8226_SUBTYPE) && > + rev4 < 0x02) > + rev4++; > + > + *major = rev4; > + if (subtype == PM8110_SUBTYPE) > + *minor = rev2; > + else > + *minor = rev3; > + > + switch (subtype) { > + case PM8941_SUBTYPE: > + *name = "pm8941"; > + break; The XXX_SUBTYPE seems are continuous why not make it an const array and get the name by index in this array? > + case PM8841_SUBTYPE: > + *name = "pm8841"; > + break; > + case PM8019_SUBTYPE: > + *name = "pm8019"; > + break; > + case PM8226_SUBTYPE: > + *name = "pm8226"; > + break; > + case PM8110_SUBTYPE: > + *name = "pm8110"; > + break; > + case PMA8084_SUBTYPE: > + *name = "pma8084"; > + break; > + case PMI8962_SUBTYPE: > + *name = "pmi8962"; > + break; > + case PMD9635_SUBTYPE: > + *name = "pmd8635"; > + break; > + case PM8994_SUBTYPE: > + *name = "pm8994"; > + break; > + case PMI8994_SUBTYPE: > + *name = "pmi8994"; > + break; > + case PM8916_SUBTYPE: > + *name = "pm8916"; > + break; > + case PM8004_SUBTYPE: > + *name = "pm8004"; > + break; > + case PM8909_SUBTYPE: > + *name = "pm8909"; > + break; > + default: > + return -EINVAL; > + } > + > + return 0; > +} > + > static const struct regmap_config spmi_regmap_config = { > .reg_bits = 16, > .val_bits = 8, > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device *sdev) > { > struct device_node *root = sdev->dev.of_node; > struct regmap *regmap; > + struct property *prop; > + int major, minor, ret; > + char *name, compatible[32]; > > regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config); > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); > + if (!ret) { Are you sure that we want to continue if we can't read the revision id and therefore will not be able to construct properly the compatible property? > + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", > + name, major, minor); > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > + if (prop) { > + prop->name = kstrdup("compatible", GFP_KERNEL); > + prop->value = kstrdup(compatible, GFP_KERNEL); > + prop->length = strlen(prop->value); > + of_update_property(root, prop); of_update_property can fail, check the returned value. <snip> -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 15:06 ` Stanimir Varbanov @ 2014-11-04 15:22 ` Ivan T. Ivanov 2014-11-04 15:26 ` Stanimir Varbanov 0 siblings, 1 reply; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-04 15:22 UTC (permalink / raw) To: Stanimir Varbanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, devicetree, linux-kernel, linux-arm-msm On Tue, 2014-11-04 at 17:06 +0200, Stanimir Varbanov wrote: > Hi Ivan, > > + > > + switch (subtype) { > > + case PM8941_SUBTYPE: > > + *name = "pm8941"; > > + break; > > The XXX_SUBTYPE seems are continuous why not make it an const array and > get the name by index in this array? > Yep, it _seems_ to be continuous. But, yes. probably using array will more compact way to represent this. <snip> > > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device *sdev) > > { > > struct device_node *root = sdev->dev.of_node; > > struct regmap *regmap; > > + struct property *prop; > > + int major, minor, ret; > > + char *name, compatible[32]; > > > > regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config); > > if (IS_ERR(regmap)) > > return PTR_ERR(regmap); > > > > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); > > + if (!ret) { > > Are you sure that we want to continue if we can't read the revision id > and therefore will not be able to construct properly the compatible > property? > Yes. Driver is working fine even without exact chip version appended to compatible string. > > + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", > > + name, major, minor); > > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > > + if (prop) { > > + prop->name = kstrdup("compatible", GFP_KERNEL); > > + prop->value = kstrdup(compatible, GFP_KERNEL); > > + prop->length = strlen(prop->value); > > + of_update_property(root, prop); > > of_update_property can fail, check the returned value. Same thing as above, but probably allocated memory at least can be freed. Thanks Ivan. > > <snip> > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 15:22 ` Ivan T. Ivanov @ 2014-11-04 15:26 ` Stanimir Varbanov 2014-11-04 15:49 ` Ivan T. Ivanov 0 siblings, 1 reply; 20+ messages in thread From: Stanimir Varbanov @ 2014-11-04 15:26 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, devicetree, linux-kernel, linux-arm-msm On 11/04/2014 05:22 PM, Ivan T. Ivanov wrote: > > On Tue, 2014-11-04 at 17:06 +0200, Stanimir Varbanov wrote: >> Hi Ivan, >> >> > + >>> + switch (subtype) { >>> + case PM8941_SUBTYPE: >>> + *name = "pm8941"; >>> + break; >> >> The XXX_SUBTYPE seems are continuous why not make it an const array and >> get the name by index in this array? >> > > Yep, it _seems_ to be continuous. But, yes. probably using array will > more compact way to represent this. > > <snip> > >>> @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device *sdev) >>> { >>> struct device_node *root = sdev->dev.of_node; >>> struct regmap *regmap; >>> + struct property *prop; >>> + int major, minor, ret; >>> + char *name, compatible[32]; >>> >>> regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config); >>> if (IS_ERR(regmap)) >>> return PTR_ERR(regmap); >>> >>> + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); >>> + if (!ret) { >> >> Are you sure that we want to continue if we can't read the revision id >> and therefore will not be able to construct properly the compatible >> property? >> > > Yes. Driver is working fine even without exact chip version > appended to compatible string. > >>> + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", >>> + name, major, minor); >>> + prop = kzalloc(sizeof(*prop), GFP_KERNEL); >>> + if (prop) { >>> + prop->name = kstrdup("compatible", GFP_KERNEL); >>> + prop->value = kstrdup(compatible, GFP_KERNEL); >>> + prop->length = strlen(prop->value); >>> + of_update_property(root, prop); >> >> of_update_property can fail, check the returned value. > > Same thing as above, but probably allocated memory at least can be freed. might be better idea to use devm_kzalloc and devm_kstrdup? -- regards, Stan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 15:26 ` Stanimir Varbanov @ 2014-11-04 15:49 ` Ivan T. Ivanov 0 siblings, 0 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-04 15:49 UTC (permalink / raw) To: Stanimir Varbanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, devicetree, linux-kernel, linux-arm-msm On Tue, 2014-11-04 at 17:26 +0200, Stanimir Varbanov wrote: > On 11/04/2014 05:22 PM, Ivan T. Ivanov wrote: > > On Tue, 2014-11-04 at 17:06 +0200, Stanimir Varbanov wrote: <snip> > > > > + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", > > > > + name, major, minor); > > > > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > > > > + if (prop) { > > > > + prop->name = kstrdup("compatible", GFP_KERNEL); > > > > + prop->value = kstrdup(compatible, GFP_KERNEL); > > > > + prop->length = strlen(prop->value); > > > > + of_update_property(root, prop); > > > > > > of_update_property can fail, check the returned value. > > > > Same thing as above, but probably allocated memory at least can be freed. > > might be better idea to use devm_kzalloc and devm_kstrdup? > compatible property is attached to device not to driver, so memory should be there even after driver is unloaded, I think. Regards, Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 13:33 [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions Ivan T. Ivanov 2014-11-04 14:56 ` Fabio Estevam [not found] ` <1415108003-16387-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> @ 2014-11-05 12:49 ` Andreas Färber 2014-11-05 13:50 ` Ivan T. Ivanov 2014-11-05 18:11 ` Bjorn Andersson 3 siblings, 1 reply; 20+ messages in thread From: Andreas Färber @ 2014-11-05 12:49 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree, linux-kernel, linux-arm-msm [-- Attachment #1: Type: text/plain, Size: 2868 bytes --] Hi, Am 04.11.2014 um 14:33 schrieb Ivan T. Ivanov: > Update compatible string with runtime detected chip revision > information, for example qcom,pm8941 will become qcom,pm8941-v1.0. That's not what the patch does though? > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com> > --- > .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 18 ++- > drivers/mfd/qcom-spmi-pmic.c | 142 +++++++++++++++++++++ > 2 files changed, 156 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > index 7182b88..bbe7db8 100644 > --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > @@ -15,10 +15,20 @@ each. A function can consume one or more of these fixed-size register regions. > > Required properties: > - compatible: Should contain one of: > - "qcom,pm8941" > - "qcom,pm8841" > - "qcom,pma8084" > - or generalized "qcom,spmi-pmic". > + qcom,pm8941, > + qcom,pm8841, > + qcom,pm8019, > + qcom,pm8226, > + qcom,pm8110, > + qcom,pma8084, > + qcom,pmi8962, > + qcom,pmd9635, > + qcom,pm8994, > + qcom,pmi8994, > + qcom,pm8916, > + qcom,pm8004, > + qcom,pm8909, Please either keep the strings consistently quoted, or drop the trailing comma to avoid any confusion of where it terminates. > + or generalized "qcom,spmi-pmic". > - reg: Specifies the SPMI USID slave address for this device. > For more information see: > Documentation/devicetree/bindings/spmi/spmi.txt Regards, Andreas [...] > @@ -45,7 +177,17 @@ static const struct of_device_id pmic_spmi_id_table[] = { > { .compatible = "qcom,spmi-pmic" }, > { .compatible = "qcom,pm8941" }, > { .compatible = "qcom,pm8841" }, > + { .compatible = "qcom,pm8019" }, > + { .compatible = "qcom,pm8226" }, > + { .compatible = "qcom,pm8110" }, > { .compatible = "qcom,pma8084" }, > + { .compatible = "qcom,pmi8962" }, > + { .compatible = "qcom,pmd9635" }, > + { .compatible = "qcom,pm8994" }, > + { .compatible = "qcom,pmi8994" }, > + { .compatible = "qcom,pm8916" }, > + { .compatible = "qcom,pm8004" }, > + { .compatible = "qcom,pm8909" }, > { } > }; > MODULE_DEVICE_TABLE(of, pmic_spmi_id_table); -- SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-05 12:49 ` Andreas Färber @ 2014-11-05 13:50 ` Ivan T. Ivanov 0 siblings, 0 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-05 13:50 UTC (permalink / raw) To: Andreas Färber Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree, linux-kernel, linux-arm-msm On Wed, 2014-11-05 at 13:49 +0100, Andreas Färber wrote: > Hi, > > Am 04.11.2014 um 14:33 schrieb Ivan T. Ivanov: > > Update compatible string with runtime detected chip revision > > information, for example qcom,pm8941 will become qcom,pm8941-v1.0. > > That's not what the patch does though? Patch add support for more chips and make compatible property more specific. Will correct description. > > > Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com> > > --- > > .../devicetree/bindings/mfd/qcom,spmi-pmic.txt | 18 ++- > > drivers/mfd/qcom-spmi-pmic.c | 142 +++++++++++++++++++++ > > 2 files changed, 156 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > > b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > > index 7182b88..bbe7db8 100644 > > --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt > > @@ -15,10 +15,20 @@ each. A function can consume one or more of these fixed-size register > > regions. > > > > Required properties: > > - compatible: Should contain one of: > > - "qcom,pm8941" > > - "qcom,pm8841" > > - "qcom,pma8084" > > - or generalized "qcom,spmi-pmic". > > + qcom,pm8941, > > + qcom,pm8841, > > + qcom,pm8019, > > + qcom,pm8226, > > + qcom,pm8110, > > + qcom,pma8084, > > + qcom,pmi8962, > > + qcom,pmd9635, > > + qcom,pm8994, > > + qcom,pmi8994, > > + qcom,pm8916, > > + qcom,pm8004, > > + qcom,pm8909, > > Please either keep the strings consistently quoted, or drop the trailing > comma to avoid any confusion of where it terminates. Sure, will fix it. Thank you, Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-04 13:33 [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions Ivan T. Ivanov ` (2 preceding siblings ...) 2014-11-05 12:49 ` Andreas Färber @ 2014-11-05 18:11 ` Bjorn Andersson 2014-11-05 18:31 ` Ivan T. Ivanov 3 siblings, 1 reply; 20+ messages in thread From: Bjorn Andersson @ 2014-11-05 18:11 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: [..] > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device *sdev) > { > struct device_node *root = sdev->dev.of_node; > struct regmap *regmap; > + struct property *prop; > + int major, minor, ret; > + char *name, compatible[32]; > > regmap = devm_regmap_init_spmi_ext(sdev, &spmi_regmap_config); > if (IS_ERR(regmap)) > return PTR_ERR(regmap); > > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); > + if (!ret) { > + snprintf(compatible, ARRAY_SIZE(compatible), "qcom,%s-v%d.%d", > + name, major, minor); > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > + if (prop) { > + prop->name = kstrdup("compatible", GFP_KERNEL); > + prop->value = kstrdup(compatible, GFP_KERNEL); > + prop->length = strlen(prop->value); > + of_update_property(root, prop); > + } > + } > + Why would you do this? What benefit does it give to patch the of_node to have a more specific compatible? It is no longer matching any compatible defined in the kernel and is anyone actually looking at this? Reading out the revid information and providing that in some way to the children could be beneficial, except for qpnp already giving you this version information per block. [..] > @@ -45,7 +177,17 @@ static const struct of_device_id pmic_spmi_id_table[] = { > { .compatible = "qcom,spmi-pmic" }, > { .compatible = "qcom,pm8941" }, > { .compatible = "qcom,pm8841" }, > + { .compatible = "qcom,pm8019" }, > + { .compatible = "qcom,pm8226" }, > + { .compatible = "qcom,pm8110" }, > { .compatible = "qcom,pma8084" }, > + { .compatible = "qcom,pmi8962" }, > + { .compatible = "qcom,pmd9635" }, > + { .compatible = "qcom,pm8994" }, > + { .compatible = "qcom,pmi8994" }, > + { .compatible = "qcom,pm8916" }, > + { .compatible = "qcom,pm8004" }, > + { .compatible = "qcom,pm8909" }, > { } This part is good, please send this out on it's own. Regards, Bjorn ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-05 18:11 ` Bjorn Andersson @ 2014-11-05 18:31 ` Ivan T. Ivanov [not found] ` <1415212271.14949.1.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-05 18:31 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote: > On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> > wrote: > [..] > > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device > > *sdev) > > { > > struct device_node *root = sdev->dev.of_node; > > struct regmap *regmap; > > + struct property *prop; > > + int major, minor, ret; > > + char *name, compatible[32]; > > > > regmap = devm_regmap_init_spmi_ext(sdev, > > &spmi_regmap_config); > > if (IS_ERR(regmap)) > > return PTR_ERR(regmap); > > > > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); > > + if (!ret) { > > + snprintf(compatible, ARRAY_SIZE(compatible), > > "qcom,%s-v%d.%d", > > + name, major, minor); > > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > > + if (prop) { > > + prop->name = kstrdup("compatible", > > GFP_KERNEL); > > + prop->value = kstrdup(compatible, > > GFP_KERNEL); > > + prop->length = strlen(prop->value); > > + of_update_property(root, prop); > > + } > > + } > > + > > Why would you do this? > What benefit does it give to patch the of_node to have a more > specific > compatible? Some of the child device drivers have to know PMIC chip revision. Regards, Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <1415212271.14949.1.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions [not found] ` <1415212271.14949.1.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> @ 2014-11-06 1:36 ` Bjorn Andersson [not found] ` <CAJAp7OgXHGWQj7MWh51LTUdmZpgZc=6m=o-Az=z8QxR7yfrw7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 20+ messages in thread From: Bjorn Andersson @ 2014-11-06 1:36 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> wrote: > > On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote: >> On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> >> wrote: >> [..] >> > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device >> > *sdev) >> > { >> > struct device_node *root = sdev->dev.of_node; >> > struct regmap *regmap; >> > + struct property *prop; >> > + int major, minor, ret; >> > + char *name, compatible[32]; >> > >> > regmap = devm_regmap_init_spmi_ext(sdev, >> > &spmi_regmap_config); >> > if (IS_ERR(regmap)) >> > return PTR_ERR(regmap); >> > >> > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); >> > + if (!ret) { >> > + snprintf(compatible, ARRAY_SIZE(compatible), >> > "qcom,%s-v%d.%d", >> > + name, major, minor); >> > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); >> > + if (prop) { >> > + prop->name = kstrdup("compatible", >> > GFP_KERNEL); >> > + prop->value = kstrdup(compatible, >> > GFP_KERNEL); >> > + prop->length = strlen(prop->value); >> > + of_update_property(root, prop); >> > + } >> > + } >> > + >> >> Why would you do this? >> What benefit does it give to patch the of_node to have a more >> specific >> compatible? > > Some of the child device drivers have to know PMIC chip revision. > So your plan is to have a strstr(parent->compatible, "-v2") there? Could you be a little bit more elaborate on what you're trying to do and which child devices that might be? Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <CAJAp7OgXHGWQj7MWh51LTUdmZpgZc=6m=o-Az=z8QxR7yfrw7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions [not found] ` <CAJAp7OgXHGWQj7MWh51LTUdmZpgZc=6m=o-Az=z8QxR7yfrw7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2014-11-06 7:54 ` Ivan T. Ivanov 2014-11-06 16:55 ` Bjorn Andersson 2014-11-08 0:08 ` Gilad Avidov 0 siblings, 2 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-06 7:54 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> wrote: > > On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote: > > > On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> > > > wrote: > > > [..] > > > > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device > > > > *sdev) > > > > { > > > > struct device_node *root = sdev->dev.of_node; > > > > struct regmap *regmap; > > > > + struct property *prop; > > > > + int major, minor, ret; > > > > + char *name, compatible[32]; > > > > > > > > regmap = devm_regmap_init_spmi_ext(sdev, > > > > &spmi_regmap_config); > > > > if (IS_ERR(regmap)) > > > > return PTR_ERR(regmap); > > > > > > > > + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); > > > > + if (!ret) { > > > > + snprintf(compatible, ARRAY_SIZE(compatible), > > > > "qcom,%s-v%d.%d", > > > > + name, major, minor); > > > > + prop = kzalloc(sizeof(*prop), GFP_KERNEL); > > > > + if (prop) { > > > > + prop->name = kstrdup("compatible", > > > > GFP_KERNEL); > > > > + prop->value = kstrdup(compatible, > > > > GFP_KERNEL); > > > > + prop->length = strlen(prop->value); > > > > + of_update_property(root, prop); > > > > + } > > > > + } > > > > + > > > > > > Why would you do this? > > > What benefit does it give to patch the of_node to have a more > > > specific > > > compatible? > > > > Some of the child device drivers have to know PMIC chip revision. > > > > So your plan is to have a strstr(parent->compatible, "-v2") there? Actually also PMIC subtype (pm8841, pm8226...) is also required, so the plan is to have something like this: { static const struct of_device_id pmic_match_table[] = { { .compatible = "qcom,pm8941-v1.0" }, { .compatible = "qcom,pm8841-v0.0" }, { } }; const struct of_device_id *match; match = of_match_device(pmic_match_table, pdev->dev.parent); if (match) { dev_info(&pdev->dev, "%s chip detected\n", match->compatible); } } > > Could you be a little bit more elaborate on what you're trying to do > and which child devices that might be? For example ADC drivers are required temperature compensation based on PMIC variant and chip manufacturer. This patch have one issue, at least :-). Using of_update_property will prevent driver to be build as module. which, I think, is coming from the fact the on first load it will modify device compatible property and will be impossible driver to match device id again. Still thinking how to overcome this. Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-06 7:54 ` Ivan T. Ivanov @ 2014-11-06 16:55 ` Bjorn Andersson 2014-11-07 15:33 ` Ivan T. Ivanov 2014-11-08 0:08 ` Gilad Avidov 1 sibling, 1 reply; 20+ messages in thread From: Bjorn Andersson @ 2014-11-06 16:55 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On Wed, Nov 5, 2014 at 11:54 PM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: >> On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: [..] >> > Some of the child device drivers have to know PMIC chip revision. >> > >> >> So your plan is to have a strstr(parent->compatible, "-v2") there? > > Actually also PMIC subtype (pm8841, pm8226...) is also required, so > the plan is to have something like this: > > { > static const struct of_device_id pmic_match_table[] = { > { .compatible = "qcom,pm8941-v1.0" }, > { .compatible = "qcom,pm8841-v0.0" }, > { } > > }; > > const struct of_device_id *match; > > match = of_match_device(pmic_match_table, pdev->dev.parent); > if (match) { > dev_info(&pdev->dev, "%s chip detected\n", match->compatible); > } > } > To me this is a hack, you should not alter the devicetree to make it "better express the hardware". Either you know these things from boot and they go in device tree, or you can probe them and they should not go in device tree. If you really need these values you should expose them through some api. >> >> Could you be a little bit more elaborate on what you're trying to do >> and which child devices that might be? > > For example ADC drivers are required temperature compensation based > on PMIC variant and chip manufacturer. > I see, is that compensation of any practical value? Or is the compensation of academic proportions? Regards, Bjorn ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-06 16:55 ` Bjorn Andersson @ 2014-11-07 15:33 ` Ivan T. Ivanov 2014-11-07 15:40 ` Ivan T. Ivanov 0 siblings, 1 reply; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-07 15:33 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm [-- Attachment #1: Type: text/plain, Size: 2421 bytes --] On Thu, 2014-11-06 at 08:55 -0800, Bjorn Andersson wrote: > On Wed, Nov 5, 2014 at 11:54 PM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: > > > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > [..] > > > > Some of the child device drivers have to know PMIC chip revision. > > > > > > > > > > So your plan is to have a strstr(parent->compatible, "-v2") there? > > > > Actually also PMIC subtype (pm8841, pm8226...) is also required, so > > the plan is to have something like this: > > > > { > > static const struct of_device_id pmic_match_table[] = { > > { .compatible = "qcom,pm8941-v1.0" }, > > { .compatible = "qcom,pm8841-v0.0" }, > > { } > > > > }; > > > > const struct of_device_id *match; > > > > match = of_match_device(pmic_match_table, pdev->dev.parent); > > if (match) { > > dev_info(&pdev->dev, "%s chip detected\n", match->compatible); > > } > > } > > > > To me this is a hack, you should not alter the devicetree to make it > "better express the hardware". Either you know these things from boot > and they go in device tree, or you can probe them and they should not > go in device tree. > > If you really need these values you should expose them through some api. I would like to avoid compile time dependency between these drivers. There are several precedents of using of_update_property() for enhancing compatible property already. > > > > Could you be a little bit more elaborate on what you're trying to do > > > and which child devices that might be? > > > > For example ADC drivers are required temperature compensation based > > on PMIC variant and chip manufacturer. > > > > I see, is that compensation of any practical value? Or is the > compensation of academic proportions? It depends of what you mean by academic :-). Attached file have test application which dump difference between non compensated and compensated values for different temperature, manufacture and input value. Output format of the program is: Column 1: manufacturer GF=0, SMIC=1, TSMC=2 Column 2: chip revision Column 3: die temperature in mili deg Celsius Column 4: input for compensation in micro Volts Column 5: compensated result in micro Volts Column 6: difference in micro Volts Regards, Ivan [-- Attachment #2: temperature-compensation-check.c --] [-- Type: text/x-csrc, Size: 14107 bytes --] #include <stdio.h> /* SW index's for PMIC type and version used by QPNP VADC and IADC */ #define REV_ID_8941_3_1 1 #define REV_ID_8026_1_0 2 #define REV_ID_8026_2_0 3 #define REV_ID_8110_1_0 4 #define REV_ID_8026_2_1 5 #define REV_ID_8110_2_0 6 #define REV_ID_8026_2_2 7 #define REV_ID_8941_3_0 8 #define REV_ID_8941_2_0 9 #define REV_ID_8916_1_0 10 #define REV_ID_8916_1_1 11 #define REV_ID_8916_2_0 12 #define FACTORY_GF 0 #define FACTORY_SMIC 1 #define FACTORY_TSMC 2 #define VBAT_COEFF_1 3000 #define VBAT_COEFF_2 45810000 #define VBAT_COEFF_3 100000 #define VBAT_COEFF_4 3500 #define VBAT_COEFF_5 80000000 #define VBAT_COEFF_6 4400 #define VBAT_COEFF_7 32200000 #define VBAT_COEFF_8 3880 #define VBAT_COEFF_9 5770 #define VBAT_COEFF_10 3660 #define VBAT_COEFF_11 5320 #define VBAT_COEFF_12 8060000 #define VBAT_COEFF_13 102640000 #define VBAT_COEFF_14 22220000 #define VBAT_COEFF_15 83060000 #define VBAT_COEFF_16 2810 #define VBAT_COEFF_17 5260 #define VBAT_COEFF_18 8027 #define VBAT_COEFF_19 2347 #define VBAT_COEFF_20 6043 #define VBAT_COEFF_21 1914 #define VBAT_OFFSET_SMIC 9446 #define VBAT_OFFSET_GF 9441 #define OCV_OFFSET_SMIC 4596 #define OCV_OFFSET_GF 5896 #define VBAT_COEFF_22 6800 #define VBAT_COEFF_23 3500 #define VBAT_COEFF_24 4360 #define VBAT_COEFF_25 8060 #define VBAT_COEFF_26 7895 #define VBAT_COEFF_27 5658 #define VBAT_COEFF_28 5760 #define VBAT_COEFF_29 7900 #define VBAT_COEFF_30 5660 #define VBAT_COEFF_31 3620 #define VBAT_COEFF_32 1230 #define VBAT_COEFF_33 5760 #define VBAT_COEFF_34 4080 #define VBAT_COEFF_35 7000 #define VBAT_COEFF_36 3040 #define VBAT_COEFF_37 3850 #define VBAT_COEFF_38 5000 #define VBAT_COEFF_39 2610 #define VBAT_COEFF_40 4190 #define VBAT_COEFF_41 5800 #define VBAT_COEFF_42 2620 #define VBAT_COEFF_43 4030 #define VBAT_COEFF_44 3230 #define VBAT_COEFF_45 3450 #define VBAT_COEFF_46 2120 #define VBAT_COEFF_47 3560 #define VBAT_COEFF_48 2190 static long qpnp_ocv_comp(int version, int factory, long result, long die_temp) { long temp_var = 0, offset = 0; if (version == REV_ID_8026_2_2) { if (die_temp > 25000) return result; } switch (version) { case REV_ID_8941_3_1: switch (factory) { case FACTORY_TSMC: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_4)); break; default: case FACTORY_GF: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_1)); break; } break; case REV_ID_8026_1_0: switch (factory) { case FACTORY_TSMC: temp_var = (((die_temp * (-VBAT_COEFF_10)) - VBAT_COEFF_14)); break; default: case FACTORY_GF: temp_var = (((die_temp * (-VBAT_COEFF_8)) + VBAT_COEFF_12)); break; } break; case REV_ID_8026_2_0: case REV_ID_8026_2_1: switch (factory) { case FACTORY_TSMC: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_10)); break; default: case FACTORY_GF: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_8)); break; } break; case REV_ID_8026_2_2: switch (factory) { case FACTORY_TSMC: result -= VBAT_COEFF_22; temp_var = (die_temp - 25000) * VBAT_COEFF_24; break; default: case FACTORY_GF: result -= VBAT_COEFF_22; temp_var = (die_temp - 25000) * VBAT_COEFF_25; break; } break; case REV_ID_8110_2_0: switch (factory) { case FACTORY_SMIC: result -= OCV_OFFSET_SMIC; if (die_temp < 25000) temp_var = VBAT_COEFF_18; else temp_var = VBAT_COEFF_19; temp_var = (die_temp - 25000) * temp_var; break; default: case FACTORY_GF: result -= OCV_OFFSET_GF; if (die_temp < 25000) temp_var = VBAT_COEFF_20; else temp_var = VBAT_COEFF_21; temp_var = (die_temp - 25000) * temp_var; break; } break; case REV_ID_8916_1_0: switch (factory) { case FACTORY_SMIC: if (die_temp < 25000) temp_var = VBAT_COEFF_26; else temp_var = VBAT_COEFF_27; temp_var = (die_temp - 25000) * temp_var; break; default: case FACTORY_GF: offset = OCV_OFFSET_GF; if (die_temp < 25000) temp_var = VBAT_COEFF_26; else temp_var = VBAT_COEFF_27; temp_var = (die_temp - 25000) * temp_var; break; } break; case REV_ID_8916_1_1: switch (factory) { /* FAB_ID is zero */ case FACTORY_GF: if (die_temp < 25000) temp_var = VBAT_COEFF_29; else temp_var = VBAT_COEFF_30; temp_var = (die_temp - 25000) * temp_var; break; /* FAB_ID is non-zero */ default: if (die_temp < 25000) temp_var = VBAT_COEFF_31; else temp_var = (-VBAT_COEFF_32); temp_var = (die_temp - 25000) * temp_var; break; } break; case REV_ID_8916_2_0: switch (factory) { case FACTORY_SMIC: offset = (-VBAT_COEFF_38); if (die_temp < 0) temp_var = die_temp * VBAT_COEFF_36; else if (die_temp > 40000) temp_var = ((die_temp - 40000) * (-VBAT_COEFF_37)); break; case FACTORY_TSMC: if (die_temp < 10000) temp_var = ((die_temp - 10000) * VBAT_COEFF_41); else if (die_temp > 50000) temp_var = ((die_temp - 50000) * (-VBAT_COEFF_42)); break; default: case FACTORY_GF: if (die_temp < 20000) temp_var = ((die_temp - 20000) * VBAT_COEFF_45); else if (die_temp > 40000) temp_var = ((die_temp - 40000) * (-VBAT_COEFF_46)); break; } break; default: temp_var = 0; break; } temp_var = temp_var / VBAT_COEFF_3; temp_var = 1000000 + temp_var; result = result * temp_var; if (offset) result -= offset; result = result / 1000000; return result; } static long qpnp_vbat_sns_comp(int version, int factory, long result, long die_temp) { long temp_var = 0, offset = 0; if (version != REV_ID_8941_3_1) { /* min(die_temp_c, 60_degC) */ if (die_temp > 60000) die_temp = 60000; } switch (version) { case REV_ID_8941_3_1: switch (factory) { case FACTORY_TSMC: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_1)); break; default: case FACTORY_GF: /* min(die_temp_c, 60_degC) */ if (die_temp > 60000) die_temp = 60000; temp_var = ((die_temp - 25000) * (-VBAT_COEFF_1)); break; } break; case REV_ID_8026_1_0: switch (factory) { case FACTORY_TSMC: temp_var = (((die_temp * (-VBAT_COEFF_11)) + VBAT_COEFF_15)); break; default: case FACTORY_GF: temp_var = (((die_temp * (-VBAT_COEFF_9)) + VBAT_COEFF_13)); break; } break; case REV_ID_8026_2_0: case REV_ID_8026_2_1: switch (factory) { case FACTORY_TSMC: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_11)); break; default: case FACTORY_GF: temp_var = ((die_temp - 25000) * (-VBAT_COEFF_9)); break; } break; case REV_ID_8026_2_2: switch (factory) { case FACTORY_TSMC: result -= VBAT_COEFF_23; temp_var = 0; break; default: case FACTORY_GF: result -= VBAT_COEFF_23; temp_var = 0; break; } break; case REV_ID_8110_2_0: switch (factory) { case FACTORY_SMIC: result -= VBAT_OFFSET_SMIC; temp_var = ((die_temp - 25000) * (VBAT_COEFF_17)); break; default: case FACTORY_GF: result -= VBAT_OFFSET_GF; temp_var = ((die_temp - 25000) * (VBAT_COEFF_16)); break; } break; case REV_ID_8916_1_0: switch (factory) { case FACTORY_SMIC: temp_var = ((die_temp - 25000) * (VBAT_COEFF_28)); break; default: case FACTORY_GF: temp_var = ((die_temp - 25000) * (VBAT_COEFF_28)); break; } break; case REV_ID_8916_1_1: switch (factory) { /* FAB_ID is zero */ case FACTORY_GF: temp_var = ((die_temp - 25000) * (VBAT_COEFF_33)); break; /* FAB_ID is non-zero */ default: offset = VBAT_COEFF_35; if (die_temp > 50000) { temp_var = ((die_temp - 25000) * (VBAT_COEFF_34)); } break; } break; case REV_ID_8916_2_0: switch (factory) { case FACTORY_SMIC: if (die_temp < 0) { temp_var = (die_temp * VBAT_COEFF_39); } else if (die_temp > 40000) { temp_var = ((die_temp - 40000) * (-VBAT_COEFF_40)); } break; case FACTORY_TSMC: if (die_temp < 10000) temp_var = ((die_temp - 10000) * VBAT_COEFF_43); else if (die_temp > 50000) temp_var = ((die_temp - 50000) * (-VBAT_COEFF_44)); break; default: case FACTORY_GF: if (die_temp < 20000) temp_var = ((die_temp - 20000) * VBAT_COEFF_47); else if (die_temp > 40000) temp_var = ((die_temp - 40000) * (-VBAT_COEFF_48)); break; } break; default: temp_var = 0; break; } temp_var = temp_var / VBAT_COEFF_3; temp_var = 1000000 + temp_var; result = result * temp_var; if (offset) result -= offset; result = result / 1000000; return result; } int main(void) { long result, original, die_temp, diff; int version, factory; printf("==================================================================\n"); printf(" OCV Compensation \n"); printf("==================================================================\n"); for (factory = FACTORY_GF; factory <= FACTORY_TSMC; factory++) { for (version = REV_ID_8941_3_1; version <= REV_ID_8916_2_0; version++) { for (die_temp = 0; die_temp <= 100000; die_temp += 10000) { for (original = 0; original <= 1800000; original += 100000) { result = qpnp_ocv_comp(version, factory, original, die_temp); diff = result - original; printf("%d\t%d\t%ld\t%ld\t%ld\t%ld\n", factory, version, die_temp, original, result, diff); } } } } printf("==================================================================\n"); printf(" VBAT Compensation \n"); printf("==================================================================\n"); for (factory = FACTORY_GF; factory <= FACTORY_TSMC; factory++) { for (version = REV_ID_8941_3_1; version <= REV_ID_8916_2_0; version++) { for (die_temp = 0; die_temp <= 100000; die_temp += 10000) { for (original = 0; original <= 1800000; original += 100000) { result = qpnp_vbat_sns_comp(version, factory, original, die_temp); diff = result - original; printf("%d\t%d\t%ld\t%ld\t%ld\t%ld\n", factory, version, die_temp, original, result, diff); } } } } return 0; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-07 15:33 ` Ivan T. Ivanov @ 2014-11-07 15:40 ` Ivan T. Ivanov [not found] ` <1415374852.26058.3.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-07 15:40 UTC (permalink / raw) To: Bjorn Andersson Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On Fri, 2014-11-07 at 17:33 +0200, Ivan T. Ivanov wrote: > On Thu, 2014-11-06 at 08:55 -0800, Bjorn Andersson wrote: > > On Wed, Nov 5, 2014 at 11:54 PM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: > > > > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > [..] > > > > > Some of the child device drivers have to know PMIC chip revision. > > > > > > > > > > > > > So your plan is to have a strstr(parent->compatible, "-v2") there? > > > > > > Actually also PMIC subtype (pm8841, pm8226...) is also required, so > > > the plan is to have something like this: > > > > > > { > > > static const struct of_device_id pmic_match_table[] = { > > > { .compatible = "qcom,pm8941-v1.0" }, > > > { .compatible = "qcom,pm8841-v0.0" }, > > > { } > > > > > > }; > > > > > > const struct of_device_id *match; > > > > > > match = of_match_device(pmic_match_table, pdev->dev.parent); > > > if (match) { > > > dev_info(&pdev->dev, "%s chip detected\n", match->compatible); > > > } > > > } > > > > > > > To me this is a hack, you should not alter the devicetree to make it > > "better express the hardware". Either you know these things from boot > > and they go in device tree, or you can probe them and they should not > > go in device tree. > > > > If you really need these values you should expose them through some api. > > I would like to avoid compile time dependency between these drivers. > There are several precedents of using of_update_property() for enhancing > compatible property already. > > > > > Could you be a little bit more elaborate on what you're trying to do > > > > and which child devices that might be? > > > > > > For example ADC drivers are required temperature compensation based > > > on PMIC variant and chip manufacturer. > > > > > > > I see, is that compensation of any practical value? Or is the > > compensation of academic proportions? > > It depends of what you mean by academic :-). Attached file have test > application which dump difference between non compensated and compensated > values for different temperature, manufacture and input value. > > Output format of the program is: > Column 1: manufacturer GF=0, SMIC=1, TSMC=2 > Column 2: chip revision > Column 3: die temperature in mili deg Celsius > Column 4: input for compensation in micro Volts > Column 5: compensated result in micro Volts > Column 6: difference in micro Volts Forgot to add. PMIC subtype and version are used also in charger and BMS drivers to workaround hardware issues. Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <1415374852.26058.3.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions [not found] ` <1415374852.26058.3.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> @ 2014-11-11 20:27 ` Courtney Cavin 2014-11-12 9:12 ` Ivan T. Ivanov 0 siblings, 1 reply; 20+ messages in thread From: Courtney Cavin @ 2014-11-11 20:27 UTC (permalink / raw) To: Ivan T. Ivanov Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm On Fri, Nov 07, 2014 at 04:40:52PM +0100, Ivan T. Ivanov wrote: > On Fri, 2014-11-07 at 17:33 +0200, Ivan T. Ivanov wrote: > > On Thu, 2014-11-06 at 08:55 -0800, Bjorn Andersson wrote: > > > On Wed, Nov 5, 2014 at 11:54 PM, Ivan T. Ivanov <iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> wrote: > > > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: [...] > > > > > Could you be a little bit more elaborate on what you're trying to do > > > > > and which child devices that might be? > > > > > > > > For example ADC drivers are required temperature compensation based > > > > on PMIC variant and chip manufacturer. > > > > > > > > > > I see, is that compensation of any practical value? Or is the > > > compensation of academic proportions? > > > > It depends of what you mean by academic :-). Attached file have test > > application which dump difference between non compensated and compensated > > values for different temperature, manufacture and input value. > > [...] > Forgot to add. PMIC subtype and version are used also in charger and BMS > drivers to workaround hardware issues. All of the blocks on the PM8x41 series have their own version numbers. There's no need to look at the chip revision. In fact, the SMBB (charger) documentation (80-NA555-12) specifically refers to the SMBB_MISC block revision registers as the method for determining the hardware version. The "qpnp-charger" SMBB driver in the CAF 3.4 & 3.10 trees utilizes block specific revision numbers, as do the "qpnp-bms" BMS driver, the "qpnp-adc-current" IADC driver, and the "qpnp-adc-voltage" VADC driver. The revision of the PMIC itself should be completely irrelevant to any of the software interfacing with it. -Courtney -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-11 20:27 ` Courtney Cavin @ 2014-11-12 9:12 ` Ivan T. Ivanov 0 siblings, 0 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-12 9:12 UTC (permalink / raw) To: Courtney Cavin Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On Tue, 2014-11-11 at 12:27 -0800, Courtney Cavin wrote: > On Fri, Nov 07, 2014 at 04:40:52PM +0100, Ivan T. Ivanov wrote: > > > > Forgot to add. PMIC subtype and version are used also in charger and BMS > > drivers to workaround hardware issues. > > All of the blocks on the PM8x41 series have their own version numbers. > There's no need to look at the chip revision. I am suspecting that, for whatever the reason is, after updates inside blocks, the PMIC chip revisions update was made instead of blocks own version update. > > In fact, the SMBB (charger) documentation (80-NA555-12) specifically It would be nice if I had this document :-). > refers to the SMBB_MISC block revision registers as the method for > determining the hardware version. The "qpnp-charger" SMBB driver in the > CAF 3.4 & 3.10 trees utilizes block specific revision numbers, as do the > "qpnp-bms" BMS driver, the "qpnp-adc-current" IADC driver, and the > "qpnp-adc-voltage" VADC driver. Hm, they read its own block revision, but they are using PMIC chip revision for workaround decisions. What could be the reason for this? > > The revision of the PMIC itself should be completely irrelevant to any > of the software interfacing with it. > It will be really nice if this is the case, but I am afraid it is not. Regards, Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-06 7:54 ` Ivan T. Ivanov 2014-11-06 16:55 ` Bjorn Andersson @ 2014-11-08 0:08 ` Gilad Avidov 2014-11-10 7:46 ` Ivan T. Ivanov 1 sibling, 1 reply; 20+ messages in thread From: Gilad Avidov @ 2014-11-08 0:08 UTC (permalink / raw) To: Ivan T. Ivanov, Bjorn Andersson Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm On 11/6/2014 12:54 AM, Ivan T. Ivanov wrote: > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: >> On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: >>> On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote: >>>> On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> >>>> wrote: >>>> [..] >>>>> @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device >>>>> *sdev) >>>>> { >>>>> struct device_node *root = sdev->dev.of_node; >>>>> struct regmap *regmap; >>>>> + struct property *prop; >>>>> + int major, minor, ret; >>>>> + char *name, compatible[32]; >>>>> >>>>> regmap = devm_regmap_init_spmi_ext(sdev, >>>>> &spmi_regmap_config); Hi Ivan, I have a general question about this driver/layer. Since the driver is using regmap, why does it need to be qcom-*spmi*-pmic ? could we drop the spmi part? regmap's point is abstraction of the bus technology, and indeed some PMICs use i2c. >>>>> if (IS_ERR(regmap)) >>>>> return PTR_ERR(regmap); >>>>> >>>>> + ret = pmic_spmi_read_revid(regmap, &name, &major, &minor); >>>>> + if (!ret) { >>>>> + snprintf(compatible, ARRAY_SIZE(compatible), >>>>> "qcom,%s-v%d.%d", >>>>> + name, major, minor); >>>>> + prop = kzalloc(sizeof(*prop), GFP_KERNEL); >>>>> + if (prop) { >>>>> + prop->name = kstrdup("compatible", >>>>> GFP_KERNEL); >>>>> + prop->value = kstrdup(compatible, >>>>> GFP_KERNEL); >>>>> + prop->length = strlen(prop->value); >>>>> + of_update_property(root, prop); >>>>> + } >>>>> + } >>>>> + >>>> Why would you do this? >>>> What benefit does it give to patch the of_node to have a more >>>> specific >>>> compatible? >>> Some of the child device drivers have to know PMIC chip revision. >>> >> So your plan is to have a strstr(parent->compatible, "-v2") there? > Actually also PMIC subtype (pm8841, pm8226...) is also required, so > the plan is to have something like this: > > { > static const struct of_device_id pmic_match_table[] = { > { .compatible = "qcom,pm8941-v1.0" }, > { .compatible = "qcom,pm8841-v0.0" }, > { } > > }; > > const struct of_device_id *match; > > match = of_match_device(pmic_match_table, pdev->dev.parent); > if (match) { > dev_info(&pdev->dev, "%s chip detected\n", match->compatible); > } > } > >> Could you be a little bit more elaborate on what you're trying to do >> and which child devices that might be? > For example ADC drivers are required temperature compensation based > on PMIC variant and chip manufacturer. > > This patch have one issue, at least :-). Using of_update_property will prevent > driver to be build as module. which, I think, is coming from the fact the > on first load it will modify device compatible property and will be impossible > driver to match device id again. Still thinking how to overcome this. > > Regards, > Ivan > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions 2014-11-08 0:08 ` Gilad Avidov @ 2014-11-10 7:46 ` Ivan T. Ivanov 0 siblings, 0 replies; 20+ messages in thread From: Ivan T. Ivanov @ 2014-11-10 7:46 UTC (permalink / raw) To: Gilad Avidov Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Stanimir Varbanov, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm Hi Gilad, On Fri, 2014-11-07 at 17:08 -0700, Gilad Avidov wrote: > On 11/6/2014 12:54 AM, Ivan T. Ivanov wrote: > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote: > > > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote: > > > > On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote: > > > > > On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov <iivanov@mm-sol.com> > > > > > wrote: > > > > > [..] > > > > > > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device > > > > > > *sdev) > > > > > > { > > > > > > struct device_node *root = sdev->dev.of_node; > > > > > > struct regmap *regmap; > > > > > > + struct property *prop; > > > > > > + int major, minor, ret; > > > > > > + char *name, compatible[32]; > > > > > > > > > > > > regmap = devm_regmap_init_spmi_ext(sdev, > > > > > > &spmi_regmap_config); > Hi Ivan, I have a general question about this driver/layer. > Since the driver is using regmap, why does it need to be > qcom-*spmi*-pmic ? could we drop the spmi part? > regmap's point is abstraction of the bus technology, and indeed some > PMICs use i2c. This is driver for SPMI device, so no. The child device/drivers are different question, but I don't want to start that discussion again. Regards, Ivan ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2014-11-12 9:12 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-11-04 13:33 [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions Ivan T. Ivanov 2014-11-04 14:56 ` Fabio Estevam 2014-11-04 15:17 ` Ivan T. Ivanov [not found] ` <1415108003-16387-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> 2014-11-04 15:06 ` Stanimir Varbanov 2014-11-04 15:22 ` Ivan T. Ivanov 2014-11-04 15:26 ` Stanimir Varbanov 2014-11-04 15:49 ` Ivan T. Ivanov 2014-11-05 12:49 ` Andreas Färber 2014-11-05 13:50 ` Ivan T. Ivanov 2014-11-05 18:11 ` Bjorn Andersson 2014-11-05 18:31 ` Ivan T. Ivanov [not found] ` <1415212271.14949.1.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> 2014-11-06 1:36 ` Bjorn Andersson [not found] ` <CAJAp7OgXHGWQj7MWh51LTUdmZpgZc=6m=o-Az=z8QxR7yfrw7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-11-06 7:54 ` Ivan T. Ivanov 2014-11-06 16:55 ` Bjorn Andersson 2014-11-07 15:33 ` Ivan T. Ivanov 2014-11-07 15:40 ` Ivan T. Ivanov [not found] ` <1415374852.26058.3.camel-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org> 2014-11-11 20:27 ` Courtney Cavin 2014-11-12 9:12 ` Ivan T. Ivanov 2014-11-08 0:08 ` Gilad Avidov 2014-11-10 7:46 ` Ivan T. Ivanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).