RE: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 27, 2013 10:05 AM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux-omap@vger.kernel.org Subject: RE: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:36 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you please pull this one? A gentle ping on this. Could you pull this one. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas- pmic.txt b/Documentation/devicetree/bindings/regulator/palmas- pmic.txt index d5a3086..5115cd7 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps659038-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 1.7.5.4 Regards, Keerthy Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 27, 2013 10:03 AM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Hi Grant, -Original Message- From: J, KEERTHY Sent: Monday, June 24, 2013 6:26 PM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; J, KEERTHY; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:35 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you pull this Please? A gentle ping on this. A gentle ping on this. Could you pull this one? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.5.4 Regards, Keerthy Regards, Keerthy Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of J, KEERTHY
Sent: Tuesday, June 25, 2013 3:51 PM
To: sa...@linux.intel.com
Cc: broo...@kernel.org; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk;
linux-omap@vger.kernel.org
Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: J, KEERTHY
Sent: Friday, June 21, 2013 2:38 PM
To: sa...@linux.intel.com
Cc: broo...@kernel.org; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org;
g...@slimlogic.co.uk;
linux-omap@vger.kernel.org
Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 20, 2013 4:32 PM
To: linux-omap@vger.kernel.org; sa...@linux.intel.com
Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org;
g...@slimlogic.co.uk
Subject: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Could you pull this one too?
A gentle ping on this.
Since the previous patch was applied by you
Even this patch needs to be taken by you.
Could you please pull this?
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/palmas-regulator.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id
of_palmas_match_tbl[]
= {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
Regards,
Keerthy
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Hi Grant, -Original Message- From: J, KEERTHY Sent: Monday, June 24, 2013 6:26 PM To: grant.lik...@secretlab.ca Cc: broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk; J, KEERTHY; linux-omap@vger.kernel.org Subject: RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:35 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you pull this Please? A gentle ping on this. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.5.4 Regards, Keerthy Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:36 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 3/4] regulators: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you please pull this one? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas- pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..5115cd7 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps659038-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 1.7.5.4 Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: J, KEERTHY
Sent: Friday, June 21, 2013 2:38 PM
To: sa...@linux.intel.com
Cc: broo...@kernel.org; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk;
linux-omap@vger.kernel.org
Subject: RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 20, 2013 4:32 PM
To: linux-omap@vger.kernel.org; sa...@linux.intel.com
Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk
Subject: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Could you pull this one too?
A gentle ping on this.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/palmas-regulator.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id
of_palmas_match_tbl[]
= {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
Regards,
Keerthy
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Hello Grant, -Original Message- From: J, KEERTHY Sent: Thursday, June 20, 2013 4:35 PM To: linux-omap@vger.kernel.org; grant.lik...@secretlab.ca Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH 1/4] MFD: Add TPS659038 documentation under Palmas Add TPS659038 documentation under Palmas. Could you pull this Please? Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.5.4 Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
-Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Monday, June 24, 2013 5:13 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support Hi, On Thu, Jun 20, 2013 at 04:35:16PM +0530, J Keerthy wrote: The Patch adds TPS659038 PMIC support in the palmas mfd driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- drivers/mfd/palmas.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Applied, thanks. Thanks Samuel. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
Hello Samuel,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 20, 2013 4:35 PM
To: linux-omap@vger.kernel.org; sa...@linux.intel.com
Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org; g...@slimlogic.co.uk
Subject: [PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier supported
variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up
battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up
convertor.
3) TPS659038 does not have Battery detection and anything related to
battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are
missing
when compared to TWL6035.
Could you please pull this patch?
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/palmas.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c index
ad2edd6..8b20055 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -233,12 +233,17 @@ static void palmas_dt_to_pdata(struct i2c_client
*i2c, }
static unsigned int palmas_features =
PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+static unsigned int tps659038_features;
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
1.7.5.4
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Hi Samuel,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 20, 2013 4:32 PM
To: linux-omap@vger.kernel.org; sa...@linux.intel.com
Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk
Subject: [PATCH 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Could you pull this one too?
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/palmas-regulator.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[]
= {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:09 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas Hi, On Wed, Jun 19, 2013 at 11:27:46AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V3: Implements Interrupts check using i2c-irq variable instead of DT interrupts property. Cleans ups in assiging the features variable in patch 2. V2: Implements Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if irq is valid MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support I took the first 2 patches, but patch #3 does not apply. Thanks. I will split 3 and 4 separating Documentation files. The Documentation was taken by Grant. So I will split the Patches 3 and 4 and send a separate series. Thanks again for pulling 1 and 2. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hi Samuel, -Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:38 PM To: J, KEERTHY Cc: broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature Hi, On Thu, Jun 20, 2013 at 04:34:42AM +, J, KEERTHY wrote: -Original Message- From: J, KEERTHY Sent: Wednesday, June 19, 2013 11:28 AM To: linux-omap@vger.kernel.org Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature From: J Keerthy j-keer...@ti.com The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
-Original Message- From: Samuel Ortiz [mailto:sa...@linux.intel.com] Sent: Thursday, June 20, 2013 2:57 PM To: J, KEERTHY Cc: broo...@kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux- ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk; linux- o...@vger.kernel.org Subject: Re: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature On Thu, Jun 20, 2013 at 09:13:06AM +, J, KEERTHY wrote: Could you please pull this patch? I'm reverting this one for now as of_match_device is not define for !CONFIG_OF. So the of_match_device parts can come under #ifdef CONFIG_OF? Nevermind, you were just missing an of_device.h inclusion. I fixed that up and applied your patch. Oops..I get it. Thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Mark Brown broo...@linaro.org
---
drivers/regulator/palmas-regulator.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: https://lkml.org/lkml/2013/6/20/156 J Keerthy (4): MFD: Add TPS659038 documentation under Palmas MFD: Palmas: Add TPS659038 PMIC support regulators: Add TPS659038 documentation under Palmas regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c |5 + drivers/regulator/palmas-regulator.c |1 + 4 files changed, 9 insertions(+), 0 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Samuel Ortiz sa...@linux.intel.com --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index 7bcd59c..89cb773 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -5,6 +5,7 @@ twl6035 (palmas) twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) +tps659038 Required properties: - compatible : Should be from the list @@ -14,6 +15,7 @@ Required properties: ti,tps65913 ti,tps65914 ti,tps80036 + ti,tps659038 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] MFD: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/palmas.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index ad2edd6..8b20055 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -233,12 +233,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
}
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+static unsigned int tps659038_features;
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] regulators: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Mark Brown broo...@linaro.org --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index d5a3086..5115cd7 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps659038-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Wednesday, June 19, 2013 10:13 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid On Wed, Jun 19, 2013 at 11:27:47AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Signed-off-by: J Keerthy j-keer...@ti.com Reviewed-by: Mark Brown broo...@linaro.org Thanks Mark. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
-Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, June 19, 2013 10:39 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid On 06/18/2013 11:57 PM, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Reviewed-by: Stephen Warren swar...@nvidia.com Thanks Stephen. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] regulator: Palmas: Add TPS659038 support
-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Wednesday, June 19, 2013 10:12 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 4/4] regulator: Palmas: Add TPS659038 support On Wed, Jun 19, 2013 at 11:27:50AM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com Add TPS659038 support. Signed-off-by: J Keerthy j-keer...@ti.com This doesn't apply against my current tree as the PMIC bindings document isn't in mainline yet. It was pulled by Grant. Acked-by: Mark Brown broo...@linaro.org assuming there's a tree where that does exist. Thanks. I will check if Grant can pull this. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid
Hi Samuel, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, June 19, 2013 10:39 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; g...@slimlogic.co.uk Subject: Re: [PATCH v3 1/4] MFD: Palmas: Check if irq is valid On 06/18/2013 11:57 PM, Keerthy wrote: From: J Keerthy j-keer...@ti.com Check if irq value obtained is valid. If it is not valid then skip the irq request step and go ahead with the probe. Reviewed-by: Stephen Warren swar...@nvidia.com Could you please pull this? Kind Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hello Samuel,
-Original Message-
From: J, KEERTHY
Sent: Wednesday, June 19, 2013 11:28 AM
To: linux-omap@vger.kernel.org
Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org; g...@slimlogic.co.uk
Subject: [PATCH v3 2/4] MFD: Palmas: Add SMPS10_BOOST feature
From: J Keerthy j-keer...@ti.com
The SMPS10 regulator is not presesnt in all the variants of the PALMAS
PMIC family. Hence adding a feature to distingush between them.
Could you please pull this patch?
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 27 --
-
drivers/regulator/palmas-regulator.c |3 +++
include/linux/mfd/palmas.h | 14 ++
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c index
b24bee3..1cacc6a 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client
*i2c,
palmas_set_pdata_irq_flag(i2c, pdata); }
+static unsigned int palmas_features =
PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -238,8 +248,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -261,9 +272,16 @@ static int palmas_i2c_probe(struct i2c_client
*i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
palmas-irq = i2c-irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-
dev);
+
+ if (!match)
+ return -ENODATA;
+
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas-i2c_clients[i] = i2c;
@@ -433,11 +451,6 @@ static const struct i2c_device_id palmas_i2c_id[]
= { }; MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
-static struct of_device_id of_palmas_match_tbl[] = {
- { .compatible = ti,palmas, },
- { /* end */ }
-};
-
static struct i2c_driver palmas_i2c_driver = {
.driver = {
.name = palmas,
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 3ae44ac..1ae1e83 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct
platform_device *pdev)
continue;
ramp_delay_support = true;
break;
+ case PALMAS_REG_SMPS10:
+ if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST))
+ continue;
}
if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8))
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8f21daf..98058ca 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -32,6 +32,19 @@
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
+/**
+ * Palmas PMIC feature types
+ *
+ * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides
SMPS10_BOOST
+ * regulator.
+ *
+ * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is
capable of a
+ * specific feature (above) or not. Return non-zero, if yes.
+ */
+#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(0)
+#define PALMAS_PMIC_HAS(b, f)\
+ ((b)-features PALMAS_PMIC_FEATURE_ ## f)
+
struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
@@ -46,6 +59,7 @@ struct palmas {
/* Stored chip id */
int id;
+ unsigned int features;
/* IRQ Data */
int irq;
u32 irq_mask;
--
1.7.5.4
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
Hi Mark, -Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Tuesday, June 18, 2013 2:28 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature On Tue, Jun 18, 2013 at 05:15:03AM +, J, KEERTHY wrote: I understand your point. The IRQ is passed from device tree node. Say if the chip for some reason is not connected to any valid IRQ line the driver might end up requesting for a wrong IRQ line. So should I be validating the irq entry populated from device tree? Yes, you should be checking that there's actually an interrupt there - the number will be zero if there isn't. Explicitly checking on chip ID helps to avoid wrongly populated Device tree data. Right, but on the other hand it ought to be possible to handle chips that could but aren't configured to do interrupts and if the driver can do that then this becomes redundant. I understood. I am now implementing this in the driver making use Of the of_parse_phandle and check if the interrupts property is Populated and only then request for irq else skip that. Hope this Approach is fine. I will send v2 in a while. Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] MFD: Palmas: Add TPS659038 PMIC support on Palmas
The Patch series adds TPS659038 PMIC support in the palmas MFD and Regulator drivers. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html V2: Implemented Interrupts checking via DT instead of creating flags and checking based on chip ID. J Keerthy (4): MFD: Palmas: Check if interrupts property exists and then only request irq MFD: Palmas: Add SMPS10_BOOST feature mfd: Palmas: Add TPS659038 PMIC support regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 + .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c | 45 drivers/regulator/palmas-regulator.c |4 ++ include/linux/mfd/palmas.h | 14 ++ 5 files changed, 58 insertions(+), 8 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq
Check if interrupts property exists and then only request irq.
On some boards INT line might not be connected to a valid
irq line on the application processor. Hence keeping a check
before requesting irq.
Boot tested on OMAP5-UEVM board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 62fa728..69c4e62 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -236,6 +236,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
{
struct palmas *palmas;
struct palmas_platform_data *pdata;
+ struct device_node *regnode = NULL;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
unsigned int reg, addr;
@@ -262,7 +263,6 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-id = id-driver_data;
- palmas-irq = i2c-irq;
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
@@ -290,6 +290,15 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ regnode = of_parse_phandle(node, interrupts, 0);
+
+ if (!regnode) {
+ dev_warn(palmas-dev, IRQ missing: skipping irq request\n);
+ goto no_irq;
+ } else {
+ palmas-irq = i2c-irq;
+ }
+
/* Change interrupt line output polarity */
if (pdata-irq_flags IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -316,6 +325,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err;
+no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] MFD: Palmas: Add SMPS10_BOOST feature
The SMPS10 regulator is not presesnt in all the variants
of the PALMAS PMIC family. Hence adding a feature to distingush
between them.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 28 +---
drivers/regulator/palmas-regulator.c |3 +++
include/linux/mfd/palmas.h | 14 ++
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 69c4e62..f9630b1 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -239,8 +249,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct device_node *regnode = NULL;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -262,7 +273,15 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
+
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-dev);
+
+ if (match) {
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+ } else {
+ return -ENODATA;
+ }
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
@@ -437,11 +456,6 @@ static const struct i2c_device_id palmas_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
-static struct of_device_id of_palmas_match_tbl[] = {
- { .compatible = ti,palmas, },
- { /* end */ }
-};
-
static struct i2c_driver palmas_i2c_driver = {
.driver = {
.name = palmas,
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 3ae44ac..1ae1e83 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
continue;
ramp_delay_support = true;
break;
+ case PALMAS_REG_SMPS10:
+ if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST))
+ continue;
}
if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8))
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8f21daf..98058ca 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -32,6 +32,19 @@
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
+/**
+ * Palmas PMIC feature types
+ *
+ * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides SMPS10_BOOST
+ * regulator.
+ *
+ * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a
+ * specific feature (above) or not. Return non-zero, if yes.
+ */
+#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(0)
+#define PALMAS_PMIC_HAS(b, f) \
+ ((b)-features PALMAS_PMIC_FEATURE_ ## f)
+
struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
@@ -46,6 +59,7 @@ struct palmas {
/* Stored chip id */
int id;
+ unsigned int features;
/* IRQ Data */
int irq;
u32 irq_mask;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Signed-off-by: J Keerthy j-keer...@ti.com
---
.../devicetree/bindings/regulator/palmas-pmic.txt |1 +
drivers/regulator/palmas-regulator.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..5115cd7 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -7,6 +7,7 @@ Required properties:
ti,twl6037-pmic
ti,tps65913-pmic
ti,tps65914-pmic
+ ti,tps659038-pmic
and also the generic series names
ti,palmas-pmic
- interrupt-parent : The parent interrupt controller which is palmas.
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] mfd: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
drivers/mfd/palmas.c |5 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index 7bcd59c..89cb773 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -5,6 +5,7 @@ twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
+tps659038
Required properties:
- compatible : Should be from the list
@@ -14,6 +15,7 @@ Required properties:
ti,tps65913
ti,tps65914
ti,tps80036
+ ti,tps659038
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index f9630b1..d8f2e33 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -232,12 +232,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
}
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+static unsigned int tps659038_features;
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/4] MFD: Palmas: Add SMPS10_BOOST feature
Hi Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Tuesday, June 18, 2013 9:23 PM
To: J, KEERTHY
Cc: linux-omap@vger.kernel.org; broo...@kernel.org;
ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca;
swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-
d...@vger.kernel.org; g...@slimlogic.co.uk
Subject: Re: [PATCH v2 2/4] MFD: Palmas: Add SMPS10_BOOST feature
On 06/18/2013 04:03 AM, J Keerthy wrote:
The SMPS10 regulator is not presesnt in all the variants of the
PALMAS
PMIC family. Hence adding a feature to distingush between them.
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl),
+i2c-dev);
+
+ if (match) {
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+ } else {
+ return -ENODATA;
+ }
I think it's more common to do the error-checking first. That way, the
success-case code doesn't need an indent:
match = of_match...(...);
if (!match)
return -ENODATA;
features = ...;
palmas-features = *features;
Sure. I will fix this.
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq
Hi Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 9:22 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 04:01 AM, J Keerthy wrote: Check if interrupts property exists and then only request irq. On some boards INT line might not be connected to a valid irq line on the application processor. Hence keeping a check before requesting irq. When there is no interrupts property, surely i2c-irq == 0, which is an invalid IRQ, and hence there's no need to check this before copying the value? The intent here is NOT to request irq with 0 or Invalid IRQ. The board File will not populate the interrupts entry if the INT line is not Connected. Hence the patch checks for the 'interrupts' property. This is essential since I do not want the probe to return error Just because the i2c-irq == 0. The explicit check for the property Ensures that the board does not have the INT line connected to A valid interrupt line on the other side. In other words, I think this whole patch could just be: + palmas-irq = i2c-irq; right? Just this will cause a probe failure. That is not what is needed. Instead the probe should continue skipping irq part. Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq
-Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 10:38 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 10:54 AM, J, KEERTHY wrote: Hi Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 9:22 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 04:01 AM, J Keerthy wrote: Check if interrupts property exists and then only request irq. On some boards INT line might not be connected to a valid irq line on the application processor. Hence keeping a check before requesting irq. When there is no interrupts property, surely i2c-irq == 0, which is an invalid IRQ, and hence there's no need to check this before copying the value? The intent here is NOT to request irq with 0 or Invalid IRQ. Sure. The board File will not populate the interrupts entry if the INT line is not Connected. Do you mean the interrupts DT property won't be present if there is no interrupt. If so, sure. Yes. Hence the patch checks for the 'interrupts' property. That shouldn't be necessary; IIRC, the I2C core has already parsed the interrupts property if there was one, and if there wasn't, it has set i2c-irq to some invalid value already. So, you simply need to check the value in i2c-irq, and don't need to look at the DT at all. Instead of checking the Invalid irq value which most likely can be 0. I am not sure. I am explicitly checking if the interrupts property exists or not. If not present then It throws out a warning. Either there is no Valid INT line connection or the DeviceTree was not populated fully. This additional piece of information is good to have in the driver IMHO. Let me know if this is rational enough to have in the driver. Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq
-Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 10:53 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 11:19 AM, J, KEERTHY wrote: -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 10:38 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 10:54 AM, J, KEERTHY wrote: Hi Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Tuesday, June 18, 2013 9:22 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 04:01 AM, J Keerthy wrote: Check if interrupts property exists and then only request irq. On some boards INT line might not be connected to a valid irq line on the application processor. Hence keeping a check before requesting irq. When there is no interrupts property, surely i2c-irq == 0, which is an invalid IRQ, and hence there's no need to check this before copying the value? The intent here is NOT to request irq with 0 or Invalid IRQ. Sure. The board File will not populate the interrupts entry if the INT line is not Connected. Do you mean the interrupts DT property won't be present if there is no interrupt. If so, sure. Yes. Hence the patch checks for the 'interrupts' property. That shouldn't be necessary; IIRC, the I2C core has already parsed the interrupts property if there was one, and if there wasn't, it has set i2c-irq to some invalid value already. So, you simply need to check the value in i2c-irq, and don't need to look at the DT at all. Instead of checking the Invalid irq value which most likely can be 0. I am not sure. I am explicitly checking if the interrupts property exists or not. If not present then It throws out a warning. Either there is no Valid INT line connection or the DeviceTree was not populated fully. This additional piece of information is good to have in the driver IMHO. Let me know if this is rational enough to have in the driver. No, you should just check the IRQ number. Hmmm...so something like (!i2c-irq) Consider this: If the device was instantiated from a board file *or* a device tree, i2c-irq is correctly set. Hence, checking that value works in both cases. If you check the interrupts DT property, that will only work if the device was instantiated from device tree, and not if it was instantiated from a board file; the property will never exist in the board file case, and hence you'll never be able to have a board file provide an interrupt. The board file approach is getting deprecated for this. I Myself removed board file related pdata stuff in one of the patches. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html So going the DeviceTree way. Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq
Hi Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, June 19, 2013 12:42 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; broo...@kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux- d...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH v2 1/4] MFD: Palmas: Check if interrupts property exists and then only request irq On 06/18/2013 11:33 AM, J, KEERTHY wrote: Stephen Warren wrote at Tuesday, June 18, 2013 10:53 PM: ... No, you should just check the IRQ number. Hmmm...so something like (!i2c-irq) Yes. Ok. Consider this: If the device was instantiated from a board file *or* a device tree, i2c-irq is correctly set. Hence, checking that value works in both cases. If you check the interrupts DT property, that will only work if the device was instantiated from device tree, and not if it was instantiated from a board file; the property will never exist in the board file case, and hence you'll never be able to have a board file provide an interrupt. The board file approach is getting deprecated for this. I Myself removed board file related pdata stuff in one of the patches. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html So going the DeviceTree way. Even if you're 100% sure this driver will only ever work with DT (which seems like a bad assumption to make no matter what the circumstance), it'd still be best to detect whether an IRQ was specified in a generic way. That way, nobody will read this driver, assume the code is generic, and just copy/paste it without thinking. Ok. I understand. I will incorporate this. Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes
Hi Benoit,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 13, 2013 10:19 PM
To: Cousson, Benoit
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk;
lee.jo...@linaro.org; devicetree-disc...@lists.ozlabs.org
Subject: RE: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and
regulator nodes
Hi Benoit,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 13, 2013 10:00 AM
To: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca;
swar...@wwwdotorg.org; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org; J, KEERTHY
Subject: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and
regulator
nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Could you please pull this patch?
A gentle ping on this patch.
Regards,
Keerthy
Regards,
Keerthy
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
V6:
Changed the order of properties.
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.
V4:
Removed splitting Palmas node.
V3:
Moved the entire Palmas device tree node to board file.
arch/arm/boot/dts/omap5-uevm.dts | 167
++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ compatible = ti,palmas;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ reg = 0x48;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9
[PATCH v2] mfd: Palmas: Remove code which is not necessary for a device tree boot
Remove code which is not necessary for a device tree boot.
Boot tested on OMAP5-UEVM board.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Laxman Dewangan ldewan...@nvidia.com
Acked-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 106 --
1 files changed, 0 insertions(+), 106 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..62fa728 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,77 +25,6 @@
#include linux/mfd/palmas.h
#include linux/of_platform.h
-enum palmas_ids {
- PALMAS_PMIC_ID,
- PALMAS_GPIO_ID,
- PALMAS_LEDS_ID,
- PALMAS_WDT_ID,
- PALMAS_RTC_ID,
- PALMAS_PWRBUTTON_ID,
- PALMAS_GPADC_ID,
- PALMAS_RESOURCE_ID,
- PALMAS_CLK_ID,
- PALMAS_PWM_ID,
- PALMAS_USB_ID,
-};
-
-static struct resource palmas_rtc_resources[] = {
- {
- .start = PALMAS_RTC_ALARM_IRQ,
- .end= PALMAS_RTC_ALARM_IRQ,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static const struct mfd_cell palmas_children[] = {
- {
- .name = palmas-pmic,
- .id = PALMAS_PMIC_ID,
- },
- {
- .name = palmas-gpio,
- .id = PALMAS_GPIO_ID,
- },
- {
- .name = palmas-leds,
- .id = PALMAS_LEDS_ID,
- },
- {
- .name = palmas-wdt,
- .id = PALMAS_WDT_ID,
- },
- {
- .name = palmas-rtc,
- .id = PALMAS_RTC_ID,
- .resources = palmas_rtc_resources[0],
- .num_resources = ARRAY_SIZE(palmas_rtc_resources),
- },
- {
- .name = palmas-pwrbutton,
- .id = PALMAS_PWRBUTTON_ID,
- },
- {
- .name = palmas-gpadc,
- .id = PALMAS_GPADC_ID,
- },
- {
- .name = palmas-resource,
- .id = PALMAS_RESOURCE_ID,
- },
- {
- .name = palmas-clk,
- .id = PALMAS_CLK_ID,
- },
- {
- .name = palmas-pwm,
- .id = PALMAS_PWM_ID,
- },
- {
- .name = palmas-usb,
- .id = PALMAS_USB_ID,
- }
-};
-
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
.reg_bits = 8,
@@ -311,7 +240,6 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
int ret = 0, i;
unsigned int reg, addr;
int slave;
- struct mfd_cell *children;
pdata = dev_get_platdata(i2c-dev);
@@ -472,42 +400,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
return ret;
}
- children = kmemdup(palmas_children, sizeof(palmas_children),
- GFP_KERNEL);
- if (!children) {
- ret = -ENOMEM;
- goto err_irq;
- }
-
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
-
- children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata-gpadc_pdata);
-
- children[PALMAS_RESOURCE_ID].platform_data = pdata-resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
- sizeof(*pdata-resource_pdata);
-
- children[PALMAS_USB_ID].platform_data = pdata-usb_pdata;
- children[PALMAS_USB_ID].pdata_size = sizeof(*pdata-usb_pdata);
-
- children[PALMAS_CLK_ID].platform_data = pdata-clk_pdata;
- children[PALMAS_CLK_ID].pdata_size = sizeof(*pdata-clk_pdata);
-
- ret = mfd_add_devices(palmas-dev, -1,
- children, ARRAY_SIZE(palmas_children),
- NULL, 0,
- regmap_irq_get_domain(palmas-irq_data));
- kfree(children);
-
- if (ret 0)
- goto err_devices;
-
return ret;
-err_devices:
- mfd_remove_devices(palmas-dev);
err_irq:
regmap_del_irq_chip(palmas-irq, palmas-irq_data);
err:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] MFD: Palmas: Add SMPS10_BOOST feature
The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |3 ++- drivers/regulator/palmas-regulator.c |3 +++ include/linux/mfd/palmas.h |4 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c index 261beb5..ad00c18 100644 --- a/drivers/mfd/palmas.c +++ b/drivers/mfd/palmas.c @@ -231,7 +231,8 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c, palmas_set_pdata_irq_flag(i2c, pdata); } -static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT; +static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT | + PALMAS_PMIC_FEATURE_SMPS10_BOOST; static unsigned int tps659038_features; diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index 3ae44ac..1ae1e83 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct platform_device *pdev) continue; ramp_delay_support = true; break; + case PALMAS_REG_SMPS10: + if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST)) + continue; } if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8)) diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h index 1b5b5f3..2a9f4d6 100644 --- a/include/linux/mfd/palmas.h +++ b/include/linux/mfd/palmas.h @@ -38,10 +38,14 @@ * PALMAS_PMIC_FEATURE_INTERRUPT - used when the PMIC has Interrupt line going * to an application processor. * + * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides SMPS10 boost + * voltage supply. + * * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a * specific feature (above) or not. Return non-zero, if yes. */ #define PALMAS_PMIC_FEATURE_INTERRUPT BIT(0) +#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(1) #define PALMAS_PMIC_HAS(b, f) \ ((b)-features PALMAS_PMIC_FEATURE_ ## f) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] MFD: Palmas: Add Interrupt feature
Palmas PMICs have an INT line. This line is one single
Interrupt line to the application processor. The interrupt
feature enables to selectively request irq for only those
specific chips which have INT line connected to a valid
IRQ line of the application processor.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 32 +---
include/linux/mfd/palmas.h | 14 ++
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 62fa728..d06ce62 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -238,8 +248,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -261,9 +272,17 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
palmas-irq = i2c-irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-dev);
+
+ if (match) {
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+ } else {
+ return -ENODATA;
+ }
+
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas-i2c_clients[i] = i2c;
@@ -290,6 +309,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ if (!PALMAS_PMIC_HAS(palmas, INTERRUPT))
+ goto no_int;
+
/* Change interrupt line output polarity */
if (pdata-irq_flags IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -316,6 +338,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err;
+no_int:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
@@ -427,11 +450,6 @@ static const struct i2c_device_id palmas_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
-static struct of_device_id of_palmas_match_tbl[] = {
- { .compatible = ti,palmas, },
- { /* end */ }
-};
-
static struct i2c_driver palmas_i2c_driver = {
.driver = {
.name = palmas,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8f21daf..1b5b5f3 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -32,6 +32,19 @@
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
+/**
+ * DOC: Palmas PMIC feature types
+ *
+ * PALMAS_PMIC_FEATURE_INTERRUPT - used when the PMIC has Interrupt line going
+ * to an application processor.
+ *
+ * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a
+ * specific feature (above) or not. Return non-zero, if yes.
+ */
+#define PALMAS_PMIC_FEATURE_INTERRUPT BIT(0)
+#define PALMAS_PMIC_HAS(b, f) \
+ ((b)-features PALMAS_PMIC_FEATURE_ ## f)
+
struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
@@ -46,6 +59,7 @@ struct palmas {
/* Stored chip id */
int id;
+ unsigned int features;
/* IRQ Data */
int irq;
u32 irq_mask;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] regulator: Palmas: Add TPS659038 support
Signed-off-by: J Keerthy j-keer...@ti.com
---
.../devicetree/bindings/regulator/palmas-pmic.txt |1 +
drivers/regulator/palmas-regulator.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..5115cd7 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -7,6 +7,7 @@ Required properties:
ti,twl6037-pmic
ti,tps65913-pmic
ti,tps65914-pmic
+ ti,tps659038-pmic
and also the generic series names
ti,palmas-pmic
- interrupt-parent : The parent interrupt controller which is palmas.
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] MFD: Palmas: Add TPS659038 PMIC to supported devices of Palmas
The Patch series adds TPS659038 PMIC support in the palmas mfd/voltage driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html J Keerthy (4): MFD: Palmas: Add Interrupt feature mfd: Palmas: Add TPS659038 PMIC support MFD: Palmas: Add SMPS10_BOOST feature regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 + .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c | 39 drivers/regulator/palmas-regulator.c |4 ++ include/linux/mfd/palmas.h | 18 + 5 files changed, 57 insertions(+), 7 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mfd: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
drivers/mfd/palmas.c |6 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index 7bcd59c..89cb773 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -5,6 +5,7 @@ twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
+tps659038
Required properties:
- compatible : Should be from the list
@@ -14,6 +15,7 @@ Required properties:
ti,tps65913
ti,tps65914
ti,tps80036
+ ti,tps659038
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d06ce62..261beb5 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -233,11 +233,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT;
+static unsigned int tps659038_features;
+
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] mfd: Palmas: Remove code which is not necessary for a device tree boot
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Samuel Ortiz Sent: Monday, June 17, 2013 6:41 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; g...@slimlogic.co.uk Subject: Re: [PATCH v2] mfd: Palmas: Remove code which is not necessary for a device tree boot Hi, On Mon, Jun 17, 2013 at 05:17:58PM +0530, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Laxman Dewangan ldewan...@nvidia.com Acked-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) Applied to mfd-next, thanks. Thanks Samuel! Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
Hi Mark, Thanks for the review. -Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Monday, June 17, 2013 9:46 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature On Mon, Jun 17, 2013 at 05:39:11PM +0530, J Keerthy wrote: Palmas PMICs have an INT line. This line is one single Interrupt line to the application processor. The interrupt feature enables to selectively request irq for only those specific chips which have INT line connected to a valid IRQ line of the application processor. Does the support for the interrupt line need to be explicitly flagged like this or can the driver not simply support an interrupt line not being configured? That would also support cases where the hardware has an interrupt line but the system integrator has opeted not to connect it for some reason which seems generally more flexible than doing things on a chip ID basis. I understand your point. The IRQ is passed from device tree node. Say if the chip for some reason is not connected to any valid IRQ line the driver might end up requesting for a wrong IRQ line. So should I be validating the irq entry populated from device tree? Explicitly checking on chip ID helps to avoid wrongly populated Device tree data. +/** + * DOC: Palmas PMIC feature types + * Is DOC: normal kerneldoc? Normal kerneldoc I shall remove DOC: Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
Remove code which is not necessary for a device tree boot.
Boot tested on OMAP5-UEVM board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 106 --
1 files changed, 0 insertions(+), 106 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..62fa728 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,77 +25,6 @@
#include linux/mfd/palmas.h
#include linux/of_platform.h
-enum palmas_ids {
- PALMAS_PMIC_ID,
- PALMAS_GPIO_ID,
- PALMAS_LEDS_ID,
- PALMAS_WDT_ID,
- PALMAS_RTC_ID,
- PALMAS_PWRBUTTON_ID,
- PALMAS_GPADC_ID,
- PALMAS_RESOURCE_ID,
- PALMAS_CLK_ID,
- PALMAS_PWM_ID,
- PALMAS_USB_ID,
-};
-
-static struct resource palmas_rtc_resources[] = {
- {
- .start = PALMAS_RTC_ALARM_IRQ,
- .end= PALMAS_RTC_ALARM_IRQ,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static const struct mfd_cell palmas_children[] = {
- {
- .name = palmas-pmic,
- .id = PALMAS_PMIC_ID,
- },
- {
- .name = palmas-gpio,
- .id = PALMAS_GPIO_ID,
- },
- {
- .name = palmas-leds,
- .id = PALMAS_LEDS_ID,
- },
- {
- .name = palmas-wdt,
- .id = PALMAS_WDT_ID,
- },
- {
- .name = palmas-rtc,
- .id = PALMAS_RTC_ID,
- .resources = palmas_rtc_resources[0],
- .num_resources = ARRAY_SIZE(palmas_rtc_resources),
- },
- {
- .name = palmas-pwrbutton,
- .id = PALMAS_PWRBUTTON_ID,
- },
- {
- .name = palmas-gpadc,
- .id = PALMAS_GPADC_ID,
- },
- {
- .name = palmas-resource,
- .id = PALMAS_RESOURCE_ID,
- },
- {
- .name = palmas-clk,
- .id = PALMAS_CLK_ID,
- },
- {
- .name = palmas-pwm,
- .id = PALMAS_PWM_ID,
- },
- {
- .name = palmas-usb,
- .id = PALMAS_USB_ID,
- }
-};
-
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
.reg_bits = 8,
@@ -311,7 +240,6 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
int ret = 0, i;
unsigned int reg, addr;
int slave;
- struct mfd_cell *children;
pdata = dev_get_platdata(i2c-dev);
@@ -472,42 +400,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
return ret;
}
- children = kmemdup(palmas_children, sizeof(palmas_children),
- GFP_KERNEL);
- if (!children) {
- ret = -ENOMEM;
- goto err_irq;
- }
-
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
-
- children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata-gpadc_pdata);
-
- children[PALMAS_RESOURCE_ID].platform_data = pdata-resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
- sizeof(*pdata-resource_pdata);
-
- children[PALMAS_USB_ID].platform_data = pdata-usb_pdata;
- children[PALMAS_USB_ID].pdata_size = sizeof(*pdata-usb_pdata);
-
- children[PALMAS_CLK_ID].platform_data = pdata-clk_pdata;
- children[PALMAS_CLK_ID].pdata_size = sizeof(*pdata-clk_pdata);
-
- ret = mfd_add_devices(palmas-dev, -1,
- children, ARRAY_SIZE(palmas_children),
- NULL, 0,
- regmap_irq_get_domain(palmas-irq_data));
- kfree(children);
-
- if (ret 0)
- goto err_devices;
-
return ret;
-err_devices:
- mfd_remove_devices(palmas-dev);
err_irq:
regmap_del_irq_chip(palmas-irq, palmas-irq_data);
err:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
Introduce features to select the appropriate sub-modules present in the palmas
variants. This adds the major features present in palmas family of PMICs.
Boot tested on OMAP5 uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 83 ++--
include/linux/mfd/palmas.h | 55 +
2 files changed, 119 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..0ca5854 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -302,6 +302,27 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_WATCHDOG |
+ PALMAS_PMIC_FEATURE_REGULATORS |
+ PALMAS_PMIC_FEATURE_BACKUP_BATTERY |
+ PALMAS_PMIC_FEATURE_32K_CLK |
+ PALMAS_PMIC_FEATURE_RTC |
+ PALMAS_PMIC_FEATURE_GPADC |
+ PALMAS_PMIC_FEATURE_USB_OTG |
+ PALMAS_PMIC_FEATURE_CHARGER_DETECT |
+ PALMAS_PMIC_FEATURE_GPIO |
+ PALMAS_PMIC_FEATURE_PWM_LED |
+ PALMAS_PMIC_FEATURE_INTERRUPT |
+ PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -309,9 +330,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
struct mfd_cell *children;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -333,9 +355,17 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
palmas-irq = i2c-irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-dev);
+
+ if (match) {
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+ } else {
+ return -ENODATA;
+ }
+
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas-i2c_clients[i] = i2c;
@@ -362,6 +392,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ if (!PALMAS_PMIC_HAS(palmas, INTERRUPT))
+ goto no_int;
+
/* Change interrupt line output polarity */
if (pdata-irq_flags IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -388,6 +421,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err;
+no_int:
+ if (!PALMAS_PMIC_HAS(palmas, GPIO))
+ goto no_gpio;
+
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
@@ -459,7 +496,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
ret = regmap_write(palmas-regmap[slave], addr, reg);
if (ret)
goto err_irq;
-
+no_gpio:
/*
* If we are probing with DT do this the DT way and return here
* otherwise continue and add devices using mfd helpers.
@@ -479,21 +516,34 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
goto err_irq;
}
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
+ if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
+ children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
+ children[PALMAS_PMIC_ID].pdata_size =
+ sizeof(*pdata-pmic_pdata);
+ }
- children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata-gpadc_pdata);
+ if (PALMAS_PMIC_HAS(palmas, GPADC)) {
+ children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
+ children[PALMAS_GPADC_ID].pdata_size =
+ sizeof(*pdata-gpadc_pdata);
+ }
- children[PALMAS_RESOURCE_ID].platform_data = pdata-resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
- sizeof
RE: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
Graeme/Laxman,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Laxman Dewangan
Sent: Friday, June 14, 2013 3:32 PM
To: Graeme Gregory
Cc: J, KEERTHY; linux-omap@vger.kernel.org;
broo...@opensource.wolfsonmicro.com; sa...@linux.intel.com
Subject: Re: [PATCH] mfd: Palmas: Introduce features to select the
appropriate modules present in the palmas variant
On Friday 14 June 2013 03:25 PM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
+ if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
+ children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
+ children[PALMAS_PMIC_ID].pdata_size =
+ sizeof(*pdata-pmic_pdata);
+ }
I think a lot of complexity here could actually be removed by
removing
the old board file style probing for palmas. I do not beleive either
major user of palmas requires that anymore? I always had in my mind
that this bit was temporary.
Completely agree, we should not have this. Also this is not valid much
in DT context and so we can remove it.
So shall I completely knock off the pdata assignments?
BTW having features flag would still be handy for PMICs which might
Not have all the features as TWL6035/Palmas. So I still want to retain
That. Is it Okay?
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes
Hi Benoit,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 13, 2013 10:00 AM
To: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk;
lee.jo...@linaro.org; J, KEERTHY
Subject: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and regulator
nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Could you please pull this patch?
Regards,
Keerthy
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
V6:
Changed the order of properties.
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.
V4:
Removed splitting Palmas node.
V3:
Moved the entire Palmas device tree node to board file.
arch/arm/boot/dts/omap5-uevm.dts | 167
++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ compatible = ti,palmas;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ reg = 0x48;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10
RE: [PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Tuesday, June 11, 2013 9:32 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and
regulator nodes
On 06/10/2013 11:30 PM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
*/
+ interrupt-parent = gic;
+ };
+};
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
I don't really see the point of splitting the node into two parts if
it's all going into a single file. It made sense if part of the node
came from a common .dtsi file, but not so much when it doesn't.
The intent was to reduce indentation and to declare its sub-nodes outside
of i2c1. I will club it and resend.
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 167 ++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2
[PATCH v5] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.
V4:
Removed splitting Palmas node.
V3:
Moved the entire Palmas device tree node to board file.
arch/arm/boot/dts/omap5-uevm.dts | 167 ++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always
RE: [PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
Hi Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Wednesday, June 12, 2013 9:22 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH v4] ARM: dts: OMAP5: Add palmas MFD node and
regulator nodes
On 06/12/2013 02:19 AM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Reviewed-by: Stephen Warren swar...@nvidia.com
Thanks..
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
*/
+ interrupt-parent = gic;
+ compatible = ti,palmas;
... although personally I prefer the compatible property to be right at
the top of each node, since it's what implies the schema for the rest
of the node. That's a tiny nit though; feel free to ignore it if the
OMAP files don't follow that convention.
Sure. I will send hopefully the last version incorporating this :-).
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
V6:
Changed the order of properties.
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.
V4:
Removed splitting Palmas node.
V3:
Moved the entire Palmas device tree node to board file.
arch/arm/boot/dts/omap5-uevm.dts | 167 ++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ compatible = ti,palmas;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ reg = 0x48;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt
[PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145 ++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt
[PATCH 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/palmas.dtsi | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..4c5162f
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = ldo4;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-name = ldo5;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-name = ldo6;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-name = ldo7;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-name = ldo8;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-name = ldo9;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-name = ldoln;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-name = ldousb;
+ };
+ };
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 145 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 243 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee Jones,
-Original Message-
From: Lee Jones [mailto:lee.jo...@linaro.org]
Sent: Monday, June 10, 2013 1:42 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk
Subject: Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap
specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-
omap-dt.git
for_3.11/dts
There's no need for this to be in the commit message.
Ok. I will remove this.
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145
++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
The interrupt property is fairly ubiqutous. There's not really any need
to document it in this manor.
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
Use the IRQ includes in dt-bindings.
Oops Yes I will include.
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
I'm a bit confused by this. Is it now common practice to break out
nodes in this way? I assume to counter mass indentation, but it's a bit
alien to me.
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
Are these all board specific, or are they shared with any other
platform?
Yes. Hence moved all of them to board file as compared to my
Last approach when I had kept all of them under palmas.dtsi.
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot
[PATCH v2 0/2] ARM: dts: Add palmas dtsi
This patch series adds palmas.dtsi and adds the omap5 specific palmas entries in the omap5-uevm board file. This patch series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.11/dts Boot tested on omap5-uevm board. J Keerthy (2): ARM: dts: add dtsi for palmas ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties arch/arm/boot/dts/omap5-uevm.dts | 147 ++ arch/arm/boot/dts/palmas.dtsi| 98 + 2 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/palmas.dtsi -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147 ++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = 150
[PATCH v2 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/palmas.dtsi | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..4c5162f
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,98 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = ldo4;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-name = ldo5;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-name = ldo6;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-name = ldo7;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-name = ldo8;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-name = ldo9;
+ };
+
+ ldoln_reg: ldoln {
+ regulator-name = ldoln;
+ };
+
+ ldousb_reg: ldousb {
+ regulator-name = ldousb;
+ };
+ };
+ };
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
Hi Laxman, -Original Message- From: Laxman Dewangan [mailto:ldewan...@nvidia.com] Sent: Monday, June 10, 2013 2:55 PM To: J, KEERTHY Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; grant.lik...@secretlab.ca; swar...@wwwdotorg.org; Stephen Warren; sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd https://lkml.org/lkml/2013/6/6/25 It is based on this. Most of time we refer from this document for dt population. Thanks, Laxman -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Hello Lee jones,
-Original Message-
From: Lee Jones [mailto:lee.jo...@linaro.org]
Sent: Monday, June 10, 2013 3:36 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk
Subject: Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap
specific palmas regulator properties
On Mon, 10 Jun 2013, J Keerthy wrote:
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147
++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
I still think this is superfluous, especially now you're using the
defines which basically say the same thing.
I retained the whole comment as it was needed to specify IRQ# as 7
And thought it completely described the below interrupt property.
I can knock it off if it is totally unnecessary.
If there are no further comments. Can I add a Reviewed-by?
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N
*/
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Benoit,
-Original Message-
From: Cousson, Benoit
Sent: Monday, June 10, 2013 3:00 PM
To: J, KEERTHY
Cc: Stephen Warren; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is based on the
patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi
b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that
it makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by
including those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this
regulator due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom
.dtsi
file for a board+pmic combination? Or have only the required
properties over ridden in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth
the effort.
I sent a V2 with only the most generic property in palmas.dtsi and the
Configurable parameter under the board file. Let me know if that patch set
Is fine.
Regards,
Benoit
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
Hi Stephen,
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Monday, June 10, 2013 9:59 PM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On 06/10/2013 03:04 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes.
Nits:
Well, you're really adding files that provide the nodes, not the nodes
themselves.
Palmas and MFD should be correctly capitalized.
Ok.
diff --git a/arch/arm/boot/dts/palmas.dtsi
b/arch/arm/boot/dts/palmas.dtsi
+palmas {
...
+ palmas_pmic {
...
+ ti,ldo6-vibrator;
Isn't that board-specific? I don't know the HW well enough to say, but
I assume that since there's a property, the whole point must be that
some boards want it set and some don't.
Yes. I will make this part of board file.
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
So the node labels here duplicate those in omap5-uevm.dts in patch 2/2.
While dtc allows this, I don't think there's much point duplicating the
labels. I'd tend to only put the labels in omap5-uevm.dts and not put
them here. That will completely avoid the possibility of the labels in
this file from conflicting with any other labels in any top-level
board.dts file.
I also wonder if this file is actually terribly useful. The only thing
that this file provides is the regulator-name property. It seems
simpler just to put that into each board.dts file. The added advantage
of doing that, is that if a board doesn't use a particular regulator,
the node won't appear, and the regulator won't get registered.
Ok. I will transfer the entire code to omap5-uevm.dts.
Thanks for the review comments.
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 170 ++
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..6fbe47c 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,174 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+};
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ regulator-min-microvolt = 300;
+ regulator-max
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; ldewan...@nvidia.com;
grant.lik...@secretlab.ca; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over ridden
in the board file?
Regards,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171 +
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = ldo1;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = ldo2;
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = ldo3;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300
RE: [PATCH] ARM: dts: add dtsi for palmas
Hi Benoit,
Thanks for the quick response.
From: Cousson, Benoit
Sent: Friday, June 07, 2013 5:57 PM
To: J, KEERTHY
Cc: devicetree-disc...@lists.ozlabs.org; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; ldewan...@nvidia.com; grant.lik...@secretlab.ca;
swar...@wwwdotorg.org; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
It looks like the board node to use palmas is missing? I cannot find it
in the previous series as well?
Yes. This is just the palmas.dtsi which will be included in the board file.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
arch/arm/boot/dts/palmas.dtsi | 171
+
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/palmas.dtsi
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
new file mode 100644
index 000..be631b5
--- /dev/null
+++ b/arch/arm/boot/dts/palmas.dtsi
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/interrupt-controller/irq.h
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
The I2C address should be there as well. We used to put it in the board
file, but this is really an I2C device specific information and not
board specific in that case.
This again i will send another patch on top of the existing board
file. That will have the I2C address. This patch only adds the
standalone palmas.dtsi.
Regards,
Keerthy
Regards,
Benoit
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-name = smps10;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always
RE: [PATCH 1/2] cpufreq: cpufreq-cpu0: support for clock which are not in DT yet.
Hi Nishanth,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Tuesday, March 12, 2013 8:06 PM
To: Cousson, Benoit
Cc: Shilimkar, Santosh; cpufreq; Rafael J. Wysocki; Shawn Guo; linux-
ker...@vger.kernel.org; linux...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 1/2] cpufreq: cpufreq-cpu0: support for clock which
are not in DT yet.
On 15:24-20130312, Benoit Cousson wrote:
Hi Guys,
On 03/12/2013 06:03 AM, Santosh Shilimkar wrote:
On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
On certain SoCs like variants of OMAP, the clock conversion to DT
is not complete. In short, the ability to:
cpus {
cpu@0 {
clocks = cpuclk 0;
};
};
is not possible. However, the clock node is registered.
Allow for clk names to be provided as string so as to be used when
needed.
Example (for OMAP3630):
cpus {
cpu@0 {
clock-name = cpufreq_ck;
};
};
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Seems a reasonable to me.
No, it is not...
You cannot add a temp binding just because the OMAP support is not
there, since the real binding already exist.
You need to register properly a clock provider to be able to
reference
it.
If you do need a hacky temp code you could do it in OMAP code but not
in the binding.
OK. My intent is to remove omap-cpufreq.c. So, I guess I could do
something like the following (not tested yet), but would that be the
right approach?
Similar attempt was done for am33xx_clks in this by Shawn:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84157.html
diff --git a/arch/arm/mach-omap2/cclock2420_data.c b/arch/arm/mach-
omap2/cclock2420_data.c
index 0f0a97c..c3017deb 100644
--- a/arch/arm/mach-omap2/cclock2420_data.c
+++ b/arch/arm/mach-omap2/cclock2420_data.c
@@ -1885,7 +1885,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, timer_32k_ck, func_32k_ck, CK_242X),
CLK(NULL, timer_sys_ck, sys_ck,CK_242X),
CLK(NULL, timer_ext_ck, alt_ck,CK_242X),
- CLK(NULL, cpufreq_ck, virt_prcm_set, CK_242X),
+ CLK(NULL, cpufreq-cpu0.0, virt_prcm_set, CK_242X),
};
diff --git a/arch/arm/mach-omap2/cclock2430_data.c b/arch/arm/mach-
omap2/cclock2430_data.c
index aed8f74..7000ca4 100644
--- a/arch/arm/mach-omap2/cclock2430_data.c
+++ b/arch/arm/mach-omap2/cclock2430_data.c
@@ -2001,7 +2001,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, timer_32k_ck, func_32k_ck, CK_243X),
CLK(NULL, timer_sys_ck, sys_ck,CK_243X),
CLK(NULL, timer_ext_ck, alt_ck,CK_243X),
- CLK(NULL, cpufreq_ck, virt_prcm_set, CK_243X),
+ CLK(NULL, cpufreq-cpu0.0, virt_prcm_set, CK_243X),
Device name and the clk_name should be interchanged right?
Something like this?
CLK(cpufreq-cpu0.0,NULL, virt_prcm_set, CK_243X),
If yes the same should apply to all the instances.
};
static const char *enable_init_clks[] = { diff --git a/arch/arm/mach-
omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..7a1dfde 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX),
CLK(NULL, timer_32k_ck, omap_32k_fck, CK_3XXX),
CLK(NULL, timer_sys_ck, sys_ck,CK_3XXX),
- CLK(NULL, cpufreq_ck, dpll1_ck, CK_3XXX),
+ CLK(NULL, cpufreq-cpu0.0, dpll1_ck, CK_3XXX),
};
static const char *enable_init_clks[] = { diff --git a/arch/arm/mach-
omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..5fad1da 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck,
CK_443X),
- CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
+ CLK(NULL, cpufreq-cpu0.0, dpll_mpu_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap
in the body of a message to majord...@vger.kernel.org More majordomo
info at
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 14, 2013 1:14 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Wed, 13 Feb 2013, J, KEERTHY wrote: So the patch needs to be rebased after 3.9 right? No, I've already done that. At this point, I don't think there's anything further that you need to do with it. Will let you know if that turns out not to be true. Ok. Thanks Paul. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, February 12, 2013 12:09 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Tue, 12 Feb 2013, J, KEERTHY wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, February 11, 2013 9:10 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Mon, 11 Feb 2013, J, KEERTHY wrote: Can I pull the other patches and rebase this patch on top of them? I need the branch where I can pull the other clock related patches. I will rebase this patch on top, Verify the PM suspend on OMAP4460 And post it. It's based on Tony's omap-for-v3.9/pm branch. I am on the above branch. I am not seeing retention with/without the patch. Sounds like you get to do some bisecting :-) Heh :-). It narrowed down to this patch: commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb Author: Paul Walmsley p...@pwsan.com Date: Sat Jan 26 00:48:54 2013 -0700 ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks Remove some leaf clocks that are actually IP block idle control points, since these should now be handled by the hwmod code. There are still a few types of MODULEMODE clocks that need to be cleaned up: - those still in use by driver or integration code - those in DEFINE_CLK_OMAP_MUX_GATE() blocks; the gate portion of these should be removed A similar process may also be possible on OMAP2/3. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com Cc: Mike Turquette mturque...@linaro.org - Paul Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, February 13, 2013 2:19 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Tue, 12 Feb 2013, J, KEERTHY wrote: Heh :-). It narrowed down to this patch: commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb Author: Paul Walmsley p...@pwsan.com Date: Sat Jan 26 00:48:54 2013 -0700 ARM: OMAP4: clock/hwmod data: start to remove some IP block control clocks Thanks, this fixes it: http://marc.info/?l=linux-omapm=136070089529743w=2 Ok. Cool. But at this point, I've rescheduled your patch to the 3.10-cleanup time frame, since we're pretty close to the 3.9 merge window. So the patch needs to be rebased after 3.9 right? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
Hi Paul, -Original Message- From: J, KEERTHY Sent: Monday, February 11, 2013 10:16 AM To: 'Paul Walmsley' Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, February 09, 2013 12:29 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags Hi Keerthy, On Fri, 8 Feb 2013, Paul Walmsley wrote: On Fri, 8 Feb 2013, J, KEERTHY wrote: Thanks for updating. Yes renaming the 'omap_clocks_register_links() Is fine. I had blindly followed the hwmod function naming convention. The new name makes sense. OK great. BTW don't forget to cc the linux-arm-kernel mailing list for all patches, otherwise we won't be able to merge the patches. Taking care of it now in this case. Just noticed during final testing of this patch that it causes some problems with power management on OMAP4460: (see the suspend/resume messages) I understand that retention is broken from the logs. I first tried seeing if the retention is working without the patch And I see that even without the patch retention fails. I am attaching the log. I just want to confirm if the retention is working fine without Applying the patch on mainline. Top Commit ID: 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39 Defconfig: omap2plus_defconfig Am I missing something here? That was a bootloader issue. I am able to see that the mainline uImage Hits retention. I could not apply the updated version of this patch from You. I guess the updated version is on top of other non merged patches. I just applied the earlier version of this patch and saw that Retention is fine on OMAP4460. Can I pull the other patches and rebase this patch on top of them? I need the branch where I can pull the other clock related patches. I will rebase this patch on top, Verify the PM suspend on OMAP4460 And post it. http://www.pwsan.com/omap/testlogs/jk_clock_flags_cleanup_3.9/20130207 1 83613/pm/4460pandaes/4460pandaes_log.txt Could you please take a look at this and see what happened? I suspect that I screwed something up as I was rebasing the patch. Unfortunately I don't have the time to debug it further. - Paul Regards, Keerthy Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, February 11, 2013 9:10 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Mon, 11 Feb 2013, J, KEERTHY wrote: Can I pull the other patches and rebase this patch on top of them? I need the branch where I can pull the other clock related patches. I will rebase this patch on top, Verify the PM suspend on OMAP4460 And post it. It's based on Tony's omap-for-v3.9/pm branch. Thanks Paul. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, February 11, 2013 9:10 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags On Mon, 11 Feb 2013, J, KEERTHY wrote: Can I pull the other patches and rebase this patch on top of them? I need the branch where I can pull the other clock related patches. I will rebase this patch on top, Verify the PM suspend on OMAP4460 And post it. It's based on Tony's omap-for-v3.9/pm branch. I am on the above branch. I am not seeing retention with/without the patch. - Paul Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Saturday, February 09, 2013 12:29 AM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] ARM: OMAP: Clock: Remove CK_* flags Hi Keerthy, On Fri, 8 Feb 2013, Paul Walmsley wrote: On Fri, 8 Feb 2013, J, KEERTHY wrote: Thanks for updating. Yes renaming the 'omap_clocks_register_links() Is fine. I had blindly followed the hwmod function naming convention. The new name makes sense. OK great. BTW don't forget to cc the linux-arm-kernel mailing list for all patches, otherwise we won't be able to merge the patches. Taking care of it now in this case. Just noticed during final testing of this patch that it causes some problems with power management on OMAP4460: (see the suspend/resume messages) I understand that retention is broken from the logs. I first tried seeing if the retention is working without the patch And I see that even without the patch retention fails. I am attaching the log. I just want to confirm if the retention is working fine without Applying the patch on mainline. Top Commit ID: 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39 Defconfig: omap2plus_defconfig Am I missing something here? http://www.pwsan.com/omap/testlogs/jk_clock_flags_cleanup_3.9/201302071 83613/pm/4460pandaes/4460pandaes_log.txt Could you please take a look at this and see what happened? I suspect that I screwed something up as I was rebasing the patch. Unfortunately I don't have the time to debug it further. - Paul Regards, Keerthy Omap4460_Panda_log_without_CK__cleanup Description: Omap4460_Panda_log_without_CK__cleanup
RE: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, January 25, 2013 2:21 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; Valentin, Eduardo; mturque...@linaro.org Subject: Re: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430 Hi, On Fri, 18 Jan 2013, J Keerthy wrote: The previous logic to detect the clocks for OMAP4460 was to combine the clocks marked as CK_443X and CK_446X. This would be fine as long as OMAP4460 was a super set of OMAP4430 clock set. This is not the case as there are clocks which are specific to OMAP4430 (for example bandgap_fclk) and some which are specific to OMAP4460(for example bandgap_ts_fclk). The clock bandgap_fclk is specific for OMAP4430 and this was added as part of OMAP4460 clock set which should not be done. Hence changing the convention. CK_446X Clocks specific to OMAP4460 CK_443X Clocks specific to OMAP4430 CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430 Boot Tested on both Panda and Panda-es. Signed-off-by: J Keerthy j-keer...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Eduardo Valentin eduardo.valen...@ti.com While I agree with this patch, my understanding is that Tony wishes to shift to list-based initialization for clocks, similar to how the hwmod initialization is done for OMAP3. This will result in moving away from the CK_* flags. There are some previous public mailing list messages on this topic that you can probably find by searching for CK_446X. Now that we've switched to the common clock framework, it should be more practical to do this conversion, since we can refer to parent clocks by name rather than by pointer. Could you please update your patch to take that approach instead? I sent a fresh patch which knocks of all the CK_* flags and creates lists For initialization of clocks similar to the hwmod approach for OMAP3. - Paul Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Friday, January 25, 2013 2:21 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; Valentin, Eduardo; mturque...@linaro.org Subject: Re: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430 Hi, On Fri, 18 Jan 2013, J Keerthy wrote: The previous logic to detect the clocks for OMAP4460 was to combine the clocks marked as CK_443X and CK_446X. This would be fine as long as OMAP4460 was a super set of OMAP4430 clock set. This is not the case as there are clocks which are specific to OMAP4430 (for example bandgap_fclk) and some which are specific to OMAP4460(for example bandgap_ts_fclk). The clock bandgap_fclk is specific for OMAP4430 and this was added as part of OMAP4460 clock set which should not be done. Hence changing the convention. CK_446X Clocks specific to OMAP4460 CK_443X Clocks specific to OMAP4430 CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430 Boot Tested on both Panda and Panda-es. Signed-off-by: J Keerthy j-keer...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Eduardo Valentin eduardo.valen...@ti.com While I agree with this patch, my understanding is that Tony wishes to shift to list-based initialization for clocks, similar to how the hwmod initialization is done for OMAP3. This will result in moving away from the CK_* flags. There are some previous public mailing list messages on this topic that you can probably find by searching for CK_446X. Now that we've switched to the common clock framework, it should be more practical to do this conversion, since we can refer to parent clocks by name rather than by pointer. Could you please update your patch to take that approach instead? Thanks for your feedback. I am in the process of removing all the CK_* flags and making separate lists instead. I am not Able to figure out where/how exactly the flag CK_TI816X Is getting used. Which family of processors are chosen Using this flag? Which clock nodes are selected using This flag? - Paul Regards, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
Hi Paul,
Any comments on this?
-Original Message-
From: J, KEERTHY
Sent: Friday, January 18, 2013 3:52 PM
To: linux-omap@vger.kernel.org; p...@pwsan.com
Cc: J, KEERTHY; Valentin, Eduardo
Subject: [PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers
for OMAP4460 and OMAP4430
The previous logic to detect the clocks for OMAP4460
was to combine the clocks marked as CK_443X and CK_446X. This would be
fine as long as OMAP4460 was a super set of OMAP4430 clock set.
This is not the case as there are clocks which are specific to OMAP4430
(for example bandgap_fclk) and some which are specific to OMAP4460(for example
bandgap_ts_fclk).
The clock bandgap_fclk is specific for OMAP4430 and
this was added as part of OMAP4460 clock set which should not be done.
Hence changing the convention.
CK_446X Clocks specific to OMAP4460
CK_443X Clocks specific to OMAP4430
CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430
Boot Tested on both Panda and Panda-es.
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c | 578
arch/arm/mach-omap2/clock.h |6 +-
2 files changed, 292 insertions(+), 292 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 5789a5e..ea349da 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1686,298 +1686,298 @@ DEFINE_CLK_MUX(auxclkreq5_ck, auxclkreq_ck_parents,
NULL, 0x0,
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
- CLK(NULL, pad_clks_src_ck, pad_clks_src_ck,
CK_443X),
- CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck,
CK_443X),
- CLK(NULL, slimbus_src_clk, slimbus_src_clk,
CK_443X),
- CLK(NULL, slimbus_clk, slimbus_clk,
CK_443X),
- CLK(NULL, sys_32k_ck, sys_32k_ck,
CK_443X),
- CLK(NULL, virt_1200_ck, virt_1200_ck,
CK_443X),
- CLK(NULL, virt_1300_ck, virt_1300_ck,
CK_443X),
- CLK(NULL, virt_1680_ck, virt_1680_ck,
CK_443X),
- CLK(NULL, virt_1920_ck, virt_1920_ck,
CK_443X),
- CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_443X),
- CLK(NULL, virt_2700_ck, virt_2700_ck,
CK_443X),
- CLK(NULL, virt_3840_ck, virt_3840_ck,
CK_443X),
- CLK(NULL, sys_clkin_ck, sys_clkin_ck,
CK_443X),
- CLK(NULL, tie_low_clock_ck, tie_low_clock_ck,
CK_443X),
- CLK(NULL, utmi_phy_clkout_ck, utmi_phy_clkout_ck,
CK_443X),
- CLK(NULL, xclk60mhsp1_ck, xclk60mhsp1_ck,
CK_443X),
- CLK(NULL, xclk60mhsp2_ck, xclk60mhsp2_ck,
CK_443X),
- CLK(NULL, xclk60motg_ck,xclk60motg_ck,
CK_443X),
- CLK(NULL, abe_dpll_bypass_clk_mux_ck,
abe_dpll_bypass_clk_mux_ck,CK_443X),
- CLK(NULL, abe_dpll_refclk_mux_ck,
abe_dpll_refclk_mux_ck,CK_443X),
- CLK(NULL, dpll_abe_ck, dpll_abe_ck,
CK_443X),
- CLK(NULL, dpll_abe_x2_ck, dpll_abe_x2_ck,
CK_443X),
- CLK(NULL, dpll_abe_m2x2_ck, dpll_abe_m2x2_ck,
CK_443X),
- CLK(NULL, abe_24m_fclk, abe_24m_fclk,
CK_443X),
- CLK(NULL, abe_clk, abe_clk,
CK_443X),
- CLK(NULL, aess_fclk,aess_fclk,
CK_443X),
- CLK(NULL, dpll_abe_m3x2_ck, dpll_abe_m3x2_ck,
CK_443X),
- CLK(NULL, core_hsd_byp_clk_mux_ck,
core_hsd_byp_clk_mux_ck, CK_443X),
- CLK(NULL, dpll_core_ck, dpll_core_ck,
CK_443X),
- CLK(NULL, dpll_core_x2_ck, dpll_core_x2_ck,
CK_443X),
- CLK(NULL, dpll_core_m6x2_ck,dpll_core_m6x2_ck,
CK_443X),
- CLK(NULL, dbgclk_mux_ck,dbgclk_mux_ck,
CK_443X),
- CLK(NULL, dpll_core_m2_ck, dpll_core_m2_ck,
CK_443X),
- CLK(NULL, ddrphy_ck,ddrphy_ck,
CK_443X),
- CLK(NULL
[PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock
The previous logic to detect the clocks for OMAP4460
was to combine the clocks marked as CK_443X and CK_446X. This would be
fine as long as OMAP4460 was a super set of OMAP4430 clock set.
This is not the case as there are clocks which are specific to OMAP4430
(for example bandgap_fclk) and some which are specific to OMAP4460(for example
bandgap_ts_fclk).
The clock bandgap_fclk is specific for OMAP4430 and
this was added as part of OMAP4460 clock set which should not be done.
Hence changing the convention.
CK_446X Clocks specific to OMAP4460
CK_443X Clocks specific to OMAP4430
CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430
Boot Tested on both Panda and Panda-es.
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c | 578
arch/arm/mach-omap2/clock.h |6 +-
2 files changed, 292 insertions(+), 292 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 5789a5e..ea349da 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1686,298 +1686,298 @@ DEFINE_CLK_MUX(auxclkreq5_ck, auxclkreq_ck_parents,
NULL, 0x0,
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
- CLK(NULL, pad_clks_src_ck, pad_clks_src_ck,
CK_443X),
- CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck,
CK_443X),
- CLK(NULL, slimbus_src_clk, slimbus_src_clk,
CK_443X),
- CLK(NULL, slimbus_clk, slimbus_clk,
CK_443X),
- CLK(NULL, sys_32k_ck, sys_32k_ck,
CK_443X),
- CLK(NULL, virt_1200_ck, virt_1200_ck,
CK_443X),
- CLK(NULL, virt_1300_ck, virt_1300_ck,
CK_443X),
- CLK(NULL, virt_1680_ck, virt_1680_ck,
CK_443X),
- CLK(NULL, virt_1920_ck, virt_1920_ck,
CK_443X),
- CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_443X),
- CLK(NULL, virt_2700_ck, virt_2700_ck,
CK_443X),
- CLK(NULL, virt_3840_ck, virt_3840_ck,
CK_443X),
- CLK(NULL, sys_clkin_ck, sys_clkin_ck,
CK_443X),
- CLK(NULL, tie_low_clock_ck, tie_low_clock_ck,
CK_443X),
- CLK(NULL, utmi_phy_clkout_ck, utmi_phy_clkout_ck,
CK_443X),
- CLK(NULL, xclk60mhsp1_ck, xclk60mhsp1_ck,
CK_443X),
- CLK(NULL, xclk60mhsp2_ck, xclk60mhsp2_ck,
CK_443X),
- CLK(NULL, xclk60motg_ck,xclk60motg_ck,
CK_443X),
- CLK(NULL, abe_dpll_bypass_clk_mux_ck,
abe_dpll_bypass_clk_mux_ck,CK_443X),
- CLK(NULL, abe_dpll_refclk_mux_ck,
abe_dpll_refclk_mux_ck,CK_443X),
- CLK(NULL, dpll_abe_ck, dpll_abe_ck,
CK_443X),
- CLK(NULL, dpll_abe_x2_ck, dpll_abe_x2_ck,
CK_443X),
- CLK(NULL, dpll_abe_m2x2_ck, dpll_abe_m2x2_ck,
CK_443X),
- CLK(NULL, abe_24m_fclk, abe_24m_fclk,
CK_443X),
- CLK(NULL, abe_clk, abe_clk,
CK_443X),
- CLK(NULL, aess_fclk,aess_fclk,
CK_443X),
- CLK(NULL, dpll_abe_m3x2_ck, dpll_abe_m3x2_ck,
CK_443X),
- CLK(NULL, core_hsd_byp_clk_mux_ck,
core_hsd_byp_clk_mux_ck, CK_443X),
- CLK(NULL, dpll_core_ck, dpll_core_ck,
CK_443X),
- CLK(NULL, dpll_core_x2_ck, dpll_core_x2_ck,
CK_443X),
- CLK(NULL, dpll_core_m6x2_ck,dpll_core_m6x2_ck,
CK_443X),
- CLK(NULL, dbgclk_mux_ck,dbgclk_mux_ck,
CK_443X),
- CLK(NULL, dpll_core_m2_ck, dpll_core_m2_ck,
CK_443X),
- CLK(NULL, ddrphy_ck,ddrphy_ck,
CK_443X),
- CLK(NULL, dpll_core_m5x2_ck,dpll_core_m5x2_ck,
CK_443X),
- CLK(NULL, div_core_ck, div_core_ck,
CK_443X),
- CLK(NULL, div_iva_hs_clk, div_iva_hs_clk,
CK_443X),
- CLK(NULL, div_mpu_hs_clk, div_mpu_hs_clk
[PATCH] ARM: OMAP2+: OMAP44XX: Clock: Correct the clock identifiers for OMAP4460 and OMAP4430
The previous logic to detect the clocks for OMAP4460
was to combine the clocks marked as CK_443X and CK_446X. This would be
fine as long as OMAP4460 was a super set of OMAP4430 clock set.
This is not the case as there are clocks which are specific to OMAP4430
(for example bandgap_fclk) and some which are specific to OMAP4460(for example
bandgap_ts_fclk).
The clock bandgap_fclk is specific for OMAP4430 and
this was added as part of OMAP4460 clock set which should not be done.
Hence changing the convention.
CK_446X Clocks specific to OMAP4460
CK_443X Clocks specific to OMAP4430
CK_44XX (CK_446X | CK_443X) Common to both OMAP4460 and OMAP4430
Boot Tested on both Panda and Panda-es.
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/cclock44xx_data.c | 578
arch/arm/mach-omap2/clock.h |6 +-
2 files changed, 292 insertions(+), 292 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 5789a5e..ea349da 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1686,298 +1686,298 @@ DEFINE_CLK_MUX(auxclkreq5_ck, auxclkreq_ck_parents,
NULL, 0x0,
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
- CLK(NULL, pad_clks_src_ck, pad_clks_src_ck,
CK_443X),
- CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck,
CK_443X),
- CLK(NULL, slimbus_src_clk, slimbus_src_clk,
CK_443X),
- CLK(NULL, slimbus_clk, slimbus_clk,
CK_443X),
- CLK(NULL, sys_32k_ck, sys_32k_ck,
CK_443X),
- CLK(NULL, virt_1200_ck, virt_1200_ck,
CK_443X),
- CLK(NULL, virt_1300_ck, virt_1300_ck,
CK_443X),
- CLK(NULL, virt_1680_ck, virt_1680_ck,
CK_443X),
- CLK(NULL, virt_1920_ck, virt_1920_ck,
CK_443X),
- CLK(NULL, virt_2600_ck, virt_2600_ck,
CK_443X),
- CLK(NULL, virt_2700_ck, virt_2700_ck,
CK_443X),
- CLK(NULL, virt_3840_ck, virt_3840_ck,
CK_443X),
- CLK(NULL, sys_clkin_ck, sys_clkin_ck,
CK_443X),
- CLK(NULL, tie_low_clock_ck, tie_low_clock_ck,
CK_443X),
- CLK(NULL, utmi_phy_clkout_ck, utmi_phy_clkout_ck,
CK_443X),
- CLK(NULL, xclk60mhsp1_ck, xclk60mhsp1_ck,
CK_443X),
- CLK(NULL, xclk60mhsp2_ck, xclk60mhsp2_ck,
CK_443X),
- CLK(NULL, xclk60motg_ck,xclk60motg_ck,
CK_443X),
- CLK(NULL, abe_dpll_bypass_clk_mux_ck,
abe_dpll_bypass_clk_mux_ck,CK_443X),
- CLK(NULL, abe_dpll_refclk_mux_ck,
abe_dpll_refclk_mux_ck,CK_443X),
- CLK(NULL, dpll_abe_ck, dpll_abe_ck,
CK_443X),
- CLK(NULL, dpll_abe_x2_ck, dpll_abe_x2_ck,
CK_443X),
- CLK(NULL, dpll_abe_m2x2_ck, dpll_abe_m2x2_ck,
CK_443X),
- CLK(NULL, abe_24m_fclk, abe_24m_fclk,
CK_443X),
- CLK(NULL, abe_clk, abe_clk,
CK_443X),
- CLK(NULL, aess_fclk,aess_fclk,
CK_443X),
- CLK(NULL, dpll_abe_m3x2_ck, dpll_abe_m3x2_ck,
CK_443X),
- CLK(NULL, core_hsd_byp_clk_mux_ck,
core_hsd_byp_clk_mux_ck, CK_443X),
- CLK(NULL, dpll_core_ck, dpll_core_ck,
CK_443X),
- CLK(NULL, dpll_core_x2_ck, dpll_core_x2_ck,
CK_443X),
- CLK(NULL, dpll_core_m6x2_ck,dpll_core_m6x2_ck,
CK_443X),
- CLK(NULL, dbgclk_mux_ck,dbgclk_mux_ck,
CK_443X),
- CLK(NULL, dpll_core_m2_ck, dpll_core_m2_ck,
CK_443X),
- CLK(NULL, ddrphy_ck,ddrphy_ck,
CK_443X),
- CLK(NULL, dpll_core_m5x2_ck,dpll_core_m5x2_ck,
CK_443X),
- CLK(NULL, div_core_ck, div_core_ck,
CK_443X),
- CLK(NULL, div_iva_hs_clk, div_iva_hs_clk,
CK_443X),
- CLK(NULL, div_mpu_hs_clk, div_mpu_hs_clk
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: J, KEERTHY j-keer...@ti.com writes: On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Well, as mentioned above, I'm waiting for Rafael's ack, then I will merge it. Because of all the arch/arm/mach-omap2/* changes, I would like to merge this via the OMAP tree to avoid conflicts with other stuff we have changing in arch/arm/mach-omap2/* OK, I had an off-line discussion with Rafael and he's OK that I take these. I will add an ack from Rafael and queue this series up for v3.6. Thanks Kevin. Thanks, Kevin -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Hi Greg, This series has Kevin's comments incorporated. Kevin, Can i have your Ack for this series? Thanks, Kevin -- Regards and Thanks, Keerthy -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman khil...@ti.com wrote: Rafael, Keerthy j-keer...@ti.com writes: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. To that end, create the AVS driver in drivers/power/avs and move the OMAP SmartReflex code to the new directory. The class driver is still retained in the mach-omap2 directory. How should we handle this for upstream? It does a bunch of cleanup under arch/arm then does the move to drivers/power the end. To avoid conflicts with other OMAP core changes, I would suggest we take this through the OMAP tree. With your ack, I'd be glad to take it. Hello Rafael, A gentle ping on this series. Thanks, Kevin -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Tue, May 8, 2012 at 3:47 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
include/linux/power/smartreflex.h | 23 ++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+ IRQSTATUS_MCUDISABLEACKINT),
SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include linux/types.h
#include linux/platform_device.h
-
+#include linux/delay.h
#include plat/voltage.h
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
I think we can use time_after()/time_before() APIs for timeout and
cpu_relax() for
tight loops instead of udelay().
cpu_relax() changes the priority everytime to low and will yield to
another thread.
Considering that we are checking the condition every microsecond does it make
some saving using cpu_relax().
cpu_relax() does not involve any priority changes or scheduling AFAICS.
Have a look at this thread:
http://www.spinics.net/lists/netdev/msg151699.html
Thanks. My bad. I meant yielding to another thread with in a space
of 1uS.
Regards
AnilKumar
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data structure
Hi Greg,
Thanks for reviewing.
On Fri, May 11, 2012 at 12:41 AM, Guyotte, Greg gguyo...@ti.com wrote:
Hi Jean,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of J, KEERTHY
Sent: Thursday, April 26, 2012 12:41 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hilman, Kevin; r...@sisk.pl; linux-ker...@vger.kernel.org; linux-
p...@lists.linux-foundation.org
Cc: Pihet-XID, Jean; J, KEERTHY; Paul Walmsley; Gopinath, Thara; Menon,
Nishanth
Subject: [PATCH V3 07/10] ARM: OMAP2+: SmartReflex: Use per-OPP data
structure
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
Furthermore, in order to make the SmartReflex implementation ready for
the move to drivers/, remove the dependency from the SR driver code
to the voltage layer by querying the data tables only from the SR device
init code.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Thara Gopinath th...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 38 +---
arch/arm/mach-omap2/sr_device.c | 36 +---
--
include/linux/power/smartreflex.h | 8 +-
3 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
omap2/smartreflex.c
index acef08d..20075de 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -347,22 +347,23 @@ static void sr_v2_disable(struct omap_sr *sr)
sr_write_reg(sr, IRQSTATUS, IRQSTATUS_MCUDISABLEACKINT);
}
-static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32 efuse_offs)
+static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row(
+ struct omap_sr *sr, u32 efuse_offs)
{
int i;
if (!sr-nvalue_table) {
dev_warn(sr-pdev-dev, %s: Missing ntarget value table\n,
__func__);
- return 0;
+ return NULL;
}
for (i = 0; i sr-nvalue_count; i++) {
if (sr-nvalue_table[i].efuse_offs == efuse_offs)
- return sr-nvalue_table[i].nvalue;
+ return sr-nvalue_table[i];
}
- return 0;
+ return NULL;
}
/* Public Functions */
@@ -586,7 +587,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
{
struct omap_volt_data *volt_data;
struct omap_sr *sr = _sr_lookup(voltdm);
- u32 nvalue_reciprocal;
+ struct omap_sr_nvalue_table *nvalue_row;
int ret;
if (IS_ERR(sr)) {
@@ -602,16 +603,16 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
return PTR_ERR(volt_data);
}
- nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data-
sr_efuse_offs);
+ nvalue_row = sr_retrieve_nvalue_row(sr, volt_data-sr_efuse_offs);
- if (!nvalue_reciprocal) {
- dev_warn(sr-pdev-dev, %s: NVALUE = 0 at voltage %ld\n,
- __func__, volt);
+ if (!nvalue_row) {
+ dev_warn(sr-pdev-dev, %s: failure getting SR data for this
voltage %ld\n,
+ __func__, volt);
return -ENODATA;
}
/* errminlimit is opp dependent and hence linked to voltage */
- sr-err_minlimit = volt_data-sr_errminlimit;
+ sr-err_minlimit = nvalue_row-errminlimit;
pm_runtime_get_sync(sr-pdev-dev);
@@ -624,7 +625,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
if (ret)
return ret;
- sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
+ sr_write_reg(sr, NVALUERECIPROCAL, nvalue_row-nvalue);
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
@@ -872,7 +873,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
struct dentry *nvalue_dir;
- struct omap_volt_data *volt_data;
int i, ret = 0;
sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -990,12 +990,10 @@ static int __init omap_sr_probe(struct
platform_device *pdev)
goto err_debugfs;
}
- omap_voltage_get_volttable(sr_info-voltdm, volt_data);
- if (!volt_data) {
- dev_warn(pdev-dev, %s: %s: No Voltage table for the
- corresponding vdd. Cannot create debugfs
- entries for n-values\n,
- __func__, sr_info-name);
+ if (sr_info-nvalue_count == 0 || !sr_info
Re: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
On Tue, May 8, 2012 at 5:25 AM, Kevin Hilman khil...@ti.com wrote:
Kevin Hilman khil...@ti.com writes:
J, KEERTHY j-keer...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks
here.
Rather than enhancing the checks, this SoC specific data should probably
just be made part of the SoC specific hwmod dev_attr.
That being said, this is an additional feature we can add after this
driver is moved.
I would like this series to concentrate on the cleanups necessary to
move to drivers/*, then additional features to support other SoCs can be
added on top.
Keerthy, please prepare a patch to generalize this to other SoCs by
using dev_attr for this SoC specific data. We can add it after this
series is merged upstream.
Kevin,
Ok. I will do that.
Thanks,
Kevin
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman khil...@ti.com wrote: AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin, I want to point out some cases of SR implementation where this may not be true. Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR. Under this, SR module issues an interrupt to ARM when there is a need to change the voltage based on temperature changes, ageing etc. Once the interrupt arrives, kernel needs to adjust voltage using regulator API. The voltage change is a micro adjustment as in other SR classes. That can easily be handled writing a plugin specific to class 2B. This driver was designed so plugins for other classes can be supported. Sure, we might need some enhancements for other classes (we already know that we will for class 1 support.) However, the purpose of this series is to do the cleanups necessary for the driver to move to drivers/*. AnilKumar, The intent of the series as explained by Kevin if to do the necessary clean up for the driver to move from mach-omap to drivers/*. We will for sure need more enhancements for other classes support. Support for additional classes can be added after the driver is moved if/when folks are motivated to post that support upstream. The SR class 2B implementation on these devices does not exist in mainline. I can point to some public repositories if you are interested in taking a look at the current code. No thanks. We can discuss it when you post support for it to mainline. Kevin Implementation of this SR method is must on at least the DM8168 device and I know some customers who are using it on their production systems. Regards AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
include/linux/power/smartreflex.h | 23 ++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+ IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include linux/types.h
#include linux/platform_device.h
-
+#include linux/delay.h
#include plat/voltage.h
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
I think we can use time_after()/time_before() APIs for timeout and
cpu_relax() for
tight loops instead of udelay().
cpu_relax() changes the priority everytime to low and will yield to
another thread.
Considering that we are checking the condition every microsecond does it make
some saving using cpu_relax().
Regards
AnilKumar
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
Hi AnilKumar,
Thanks for reviewing.
On Fri, May 4, 2012 at 2:00 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/mach-omap2/smartreflex.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 144d118..15907b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_mpu_irqs[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = sr1,
+ .name = smartreflex_mpu_iva,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info
omap3_smartreflex_core_irqs[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
@@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = sr2,
+ .name = smartreflex_core,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2edd1e2..d859277 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, smartreflex_mpu_iva))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks here.
Regards
AnilKumar
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY j-keer...@ti.com wrote: On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman khil...@ti.com wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. Yes, and that was a part of my concern, but see below. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) Right, that's what I'd understood it to be. The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. It's not just a driver, though - it's also creating this power/avs thing, though now I look at the code rather than just its shape there's not actually an abstraction being added here, it's mostly just straight code motion of the arch/arm code that's there already. The changelog and the shape of the code make it sound like this is intended to be somewhat generic when really it's providing some OMAP specific tuning for the device which is much less of a concern. I guess for now it's probably OK to just clarify in the documentation and say that whoever adds the second driver has to work on making this generic :) Agreed. In a different thread (which I can't seem to find now) we discussed this as well, so it just sounds like the changelog should clarify this a bit better. Kevin/Mark, Thanks for the feedback. I will add more documentation to clarify this aspect. Please let me know if there are any more things to be taken care of in this patch set. Hello Kevin, A gentle ping on this series. Any comments on this? Kevin This does also sound rather like it's in a similar area to the current management work which Durgadoss R (CCed) was working on, though with a slightly different application and in the OMAP case it's pretty much all hidden in the external processor. -- Regards and Thanks, Keerthy -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman khil...@ti.com wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. Yes, and that was a part of my concern, but see below. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) Right, that's what I'd understood it to be. The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. It's not just a driver, though - it's also creating this power/avs thing, though now I look at the code rather than just its shape there's not actually an abstraction being added here, it's mostly just straight code motion of the arch/arm code that's there already. The changelog and the shape of the code make it sound like this is intended to be somewhat generic when really it's providing some OMAP specific tuning for the device which is much less of a concern. I guess for now it's probably OK to just clarify in the documentation and say that whoever adds the second driver has to work on making this generic :) Agreed. In a different thread (which I can't seem to find now) we discussed this as well, so it just sounds like the changelog should clarify this a bit better. Kevin/Mark, Thanks for the feedback. I will add more documentation to clarify this aspect. Please let me know if there are any more things to be taken care of in this patch set. Kevin This does also sound rather like it's in a similar area to the current management work which Durgadoss R (CCed) was working on, though with a slightly different application and in the OMAP case it's pretty much all hidden in the external processor. -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Sat, Apr 28, 2012 at 2:31 AM, Kevin Hilman khil...@ti.com wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin [1] Figure 3-76 in OMAP4430 ES2.1 Public TRM vAD provides a detailed diagram: http://www.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vAD.zip Thanks for the detailed answer Kevin. -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
Hello Mark, On Fri, Apr 27, 2012 at 12:41 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote: From: J Keerthy j-keer...@ti.com AVS(Adaptive Voltage Scaling) is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). The TI AVS solution is named Smartreflex. What's the relationship between this and existing things like devfreq and cpufreq? It'd be better if the changelogs made this clear and provided an overview of how all these different subsystems are intended to fit together. Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. SmartReflex is a technology that uses adaptive power supply to achieve the goal of reducing active power consumption. With SmartReflex, the power supply voltage can be adapted to the silicon performance either statically (for example, adapted to the manufacturing process of a given device), or dynamically (for example, adapted to the temperature induced current performance of the device). So for every OPP(voltage/frequency pair) depending on the silicon process and temperature the Smartreflex tries to get the voltage to an optimal value at which the corresponding frequency can be sustained. -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 5430 adc to temp
Sorry for the Spam! On Wed, Oct 19, 2011 at 4:37 PM, J, KEERTHY j-keer...@ti.com wrote: -- Regards and Thanks, Keerthy -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: OMAP4460+: System control module driver
On Fri, Sep 23, 2011 at 12:20 PM, Paul Walmsley p...@pwsan.com wrote: Hi some comments: On Thu, 22 Sep 2011, Keerthy wrote: The system control module has several components. On die temperature is a part of system control module. The system control module driver registers the temperature sensor as a client. A hwmon driver for temperature sensor to route the temperature and the thresholds to the user space. The system control module driver patch depends on the following series found here: http://comments.gmane.org/gmane.linux.ports.arm.omap/64436 Signed-off-by: Keerthy j-keer...@ti.com Cc:sa...@linux.intel.com This should also be sent to the linux-arm-ker...@lists.infradead.org and linux-ker...@vger.kernel.org lists as well as the linux-omap list. Ok --- drivers/mfd/Kconfig | 9 + drivers/mfd/Makefile | 2 +- drivers/mfd/omap4460plus_scm.c | 581 3 files changed, 591 insertions(+), 1 deletions(-) create mode 100644 drivers/mfd/omap4460plus_scm.c Index: linux-omap-2.6/drivers/mfd/Kconfig === --- linux-omap-2.6.orig/drivers/mfd/Kconfig 2011-09-22 18:35:25.636575640 +0530 +++ linux-omap-2.6/drivers/mfd/Kconfig 2011-09-22 18:35:43.412576517 +0530 @@ -212,6 +212,15 @@ and other features that are often used in portable devices like cell phones and PDAs. +config OMAP4460PLUS_SCM + bool Texas Instruments OMAP4460 System control module + depends on ARCH_OMAP OMAP_SCM_DEV + help + If you say yes here you get support for the Texas Instruments + OMAP4460 system control module. This includes support for + on die temperature sensor which is a part of System control + module. + It seems to me that this driver should work for the OMAP4430 as well. Is there a reason why this is marked as OMAP4460 all over? Ok. The system control module should work for OMAP4430 as well. The temperature sensor is different for OMAP4430 and OMAP4460. The register layout and functionality and even the programming model is different. So i plan to keep the SCM driver common and make temperature sensor driver OMAP4460PLUS. Is this approach fine? Please let me know about your thoughts on this. config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS Index: linux-omap-2.6/drivers/mfd/Makefile === --- linux-omap-2.6.orig/drivers/mfd/Makefile 2011-09-22 18:35:25.604576115 +0530 +++ linux-omap-2.6/drivers/mfd/Makefile 2011-09-22 18:35:43.416576975 +0530 @@ -42,7 +42,7 @@ obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o obj-$(CONFIG_MENELAUS) += menelaus.o - +obj-$(CONFIG_OMAP4460PLUS_SCM) += omap4460plus_scm.o obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o obj-$(CONFIG_TWL4030_POWER) += twl4030-power.o Index: linux-omap-2.6/drivers/mfd/omap4460plus_scm.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-omap-2.6/drivers/mfd/omap4460plus_scm.c 2011-09-22 18:53:05.132583900 +0530 Please split this file into at least two files, as is the standard practice for MFD drivers. There should be one omap4-scm-core.c file, and one omap4-scm-tempsensor.c file. Everything temperature sensor-specific should go into the omap4-scm-tempsensor.c file. Ok. I will have two files one as core and one for temperature sensor. @@ -0,0 +1,581 @@ +/* + * OMAP4 system control module driver file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * Author: Moiz Sonasath m-sonas...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#include linux/interrupt.h +#include linux/clk.h +#include linux/io.h +#include linux/slab.h +#include linux/platform_device.h +#include plat/omap_device.h +#include linux/kernel.h +#include linux/jiffies.h +#include linux/err.h +#include linux/types.h +#include
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Sat, Sep 24, 2011 at 1:18 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 23 Sep 2011, J, KEERTHY wrote: On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 22 Sep 2011, Keerthy wrote: @@ -0,0 +1,175 @@ +/* + * OMAP system control module header file + * + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ + * Author: J Keerthy j-keer...@ti.com + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ + +#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_TEMPERATURE_SENSOR_H +#define __ARCH_ARM_PLAT_OMAP_INCLUDE_PLAT_TEMPERATURE_SENSOR_H You're also missing important #includes here for things like mutexes and kernel types that you use later on in the file. Those header files are included in c files. And how does that affect my comment? +#define OMAP_ADC_START_VALUE 530 +#define OMAP_ADC_END_VALUE 923 Are these OMAP4460, OMAP4xxx, or OMAP2+ specific? OMAP4460. I will pass even these values through pdata since they differ from platform to platform. So then the macro names need to include OMAP4460 or whatever SoC they are first valid for. + +/** + * struct omap4460plus_scm_dev_attr - device attributes for scm There are loads of references to 'omap4460plus' when it seems to me that much of this driver should also apply to OMAP4430 also. Shouldn't this driver be named something like 'omap4430plus_scm' or even better 'omap4_scm' ? This is used by hwmod. Hence keeping it in the header file. Did you even read my comment before responding? Sorry about this. OMAP4430 and OMAP4460 temperature sensors are different. The register layout and the functionalities differ. The OMAP4430 temperature sensor is not accurate. The SCM driver can be generic but the temperature sensor driver should be OMAP4460 onwards. Please let me know if this is fine? - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Sat, Sep 24, 2011 at 1:29 PM, Paul Walmsley p...@pwsan.com wrote: On Fri, 23 Sep 2011, J, KEERTHY wrote: On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 22 Sep 2011, Keerthy wrote: diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c b/arch/arm/mach-omap2/temp_sensor4460_data.c new file mode 100644 index 000..2804615 --- /dev/null +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c Is there some reason why this shouldn't go into drivers/ in some form? This is used by mach-omap2. Why does something in mach-omap2 need this data? The scm hwmod is populating the pointer to the register set which is specific to OMAP4460. So i have kept the OMAP4460 specific data file in mach-omap2. diff --git a/arch/arm/plat-omap/include/plat/scm.h b/arch/arm/plat-omap/include/plat/scm.h new file mode 100644 index 000..47aa38f --- /dev/null +++ b/arch/arm/plat-omap/include/plat/scm.h If this is being used by a driver, then this header file should go into the appropriate drivers/ subdirectory. If it is being used by code in arch/arm/mach-omap2, then please use the existing arch/arm/mach-omap2/control.h instead. The header file has structures used both by drivers/ and mach-omap. So kept it in plat-omap. The point is, if there are structure definitions and macros that are only needed by code in drivers/, then those should be split off into a separate file and placed in drivers/. Similarly, if there are elements of this file that are only used in mach-omap2/, then those should go into mach-omap2/control.h. About the only part off the top of my head that should go into a plat-omap header file should be the dev_attr structure. And it's debatable whether this driver even needs a dev_attr, or whether all this data should just go into an omap4460_scm.c MFD driver that uses a bunch of common code for the parts that are shared with 4430, etc. Do you have any views on this issue? There can be a common omap4_scm.c driver. The temperature sensor is different from OMAP4430 and OMAP4460. So keeping the temperature sensor as omap4460plus. Coming to structure definitions. pdata structure is needed both by mach-omap device file to populate it and also by the driver t extract it. So keeping all of the structure definitions in one header file in plat_omap. My question is which is the ideal place to keep the common structure definition like pdata? Since the temperature sensor does not have a separate hwmod of its own i feel there is a necessity of dev_attr. - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor
On Fri, Sep 23, 2011 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, J, KEERTHY wrote:
On Fri, Sep 23, 2011 at 10:48 AM, Paul Walmsley p...@pwsan.com wrote:
On Thu, 22 Sep 2011, Keerthy wrote:
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 946bf04..c51e513 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3185,9 +3185,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, aes2_fck, aes2_fck,
CK_443X),
CLK(NULL, aess_fck, aess_fck,
CK_443X),
CLK(NULL, bandgap_fclk, bandgap_fclk,
CK_443X),
- CLK(NULL, bandgap_ts_fclk, bandgap_ts_fclk,
CK_446X),
+ CLK(omap4460plus_scm.0, fck, bandgap_ts_fclk,
CK_446X),
CLK(NULL, des3des_fck, des3des_fck,
CK_443X),
- CLK(NULL, div_ts_ck, div_ts_ck,
CK_446X),
+ CLK(omap4460plus_scm.0, div_ck,
div_ts_ck, CK_446X),
Clearly this device is incorrectly named. You're setting up a clkdev
entry that's marked as being valid for OMAP4430, but your device is called
omap4460plus_scm. They can't both be right...
This is addressed in Patch 06.
How does patch 6 address it?
I am not sure i interpreted the comment right. These clock nodes are specific to
OMAP4460 and are tagged CK_446X hence the device name omap4460plus_scm.0
- Paul
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
some comments
On Thu, 22 Sep 2011, Keerthy wrote:
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/temp_sensor4460_data.c | 115 ++
arch/arm/plat-omap/include/plat/scm.h | 175
3 files changed, 291 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
create mode 100644 arch/arm/plat-omap/include/plat/scm.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 46a3497..e6f8d36 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -86,7 +86,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o
cm2xxx_3xxx.o prm2xxx_3xxx.o \
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
- vp44xx_data.o
+ vp44xx_data.o temp_sensor4460_data.o
This is not part of the PRCM, so it should not be added here.
It also should be conditional on CONFIG_SOC_OMAP4460. If that Kconfig
entry doesn't exist, it should be added.
Ok. I will add it.
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..2804615
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
Is there some reason why this shouldn't go into drivers/ in some form?
This is used by mach-omap2.
@@ -0,0 +1,115 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/slab.h
+#include control.h
+#include plat/scm.h
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
This is going to break if we want to compile a kernel with support
for, say, the 4430 and 4460 temperature sensors.
Ok. I will rename this as omap4460_temp_sensor_registers
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask = OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask = OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold = OMAP4460_BGAP_TSHUT_OFFSET,
tshut is misspelled.
I will correct this.
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask = OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status = OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK
Re: [PATCH 4/6] OMAP4: Hwmod: system control module hwmod
On Fri, Sep 23, 2011 at 11:45 AM, Paul Walmsley p...@pwsan.com wrote: + Benoît Hi, On Thu, 22 Sep 2011, Keerthy wrote: From: Benoit Cousson b-cous...@ti.com Adding the system control module hwmod. Have the autogeneration scripts been updated ? The hwmod is autogenerated. I have taken this from Benoit. I have added the dev_attr to pass on the information about temperature sensors. Signed-off-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Keerthy j-keer...@ti.com - Paul -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
