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 > > > Acked-by: Samuel Ortiz > > > --- > > > 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 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 > > Acked-by: Mark Brown > > --- > > .../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 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 > Acked-by: Mark Brown > --- > .../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 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 > > Acked-by: Samuel Ortiz > > --- > > 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 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
> > > Acked-by: Mark Brown
> > > ---
> > > 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 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
> > Acked-by: Mark Brown
> > ---
> > 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 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 > > Acked-by: Samuel Ortiz > > --- > > 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 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 > Acked-by: Samuel Ortiz > --- > 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 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
> Acked-by: Mark Brown
> ---
> 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 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
> Acked-by: Samuel Ortiz
> ---
> 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
[PATCH 3/4] regulators: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy Acked-by: Mark Brown --- .../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
[PATCH 1/4] MFD: Add TPS659038 documentation under Palmas
Add TPS659038 documentation under Palmas. Signed-off-by: J Keerthy Acked-by: Samuel Ortiz --- 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
Acked-by: Samuel Ortiz
---
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 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 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Signed-off-by: J Keerthy
Acked-by: Mark Brown
---
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
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
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 > > > > > > 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 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 > > > > 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
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
>
> 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
> ---
> 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 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 > > > > 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 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 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 > > > > 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 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 > > > > Add TPS659038 support. > > > > Signed-off-by: J Keerthy > > 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 > > 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
> -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 > > > > 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 > > Reviewed-by: Mark Brown 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 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 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
> -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
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 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
[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
---
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
[PATCH v2 4/4] regulator: Palmas: Add TPS659038 support
Add TPS659038 support.
Signed-off-by: J Keerthy
---
.../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 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
---
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 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
---
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 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
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
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
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 > > Acked-by: Laxman Dewangan > > Acked-by: Graeme Gregory > > --- > > 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
[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
---
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
---
.../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
---
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
[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 --- 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 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
Acked-by: Laxman Dewangan
Acked-by: Graeme Gregory
---
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
#include
-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
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
> > Signed-off-by: J Keerthy
> > Reviewed-by: Stephen Warren
> > ---
> > 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
> > +#include
> >
> > / {
> > model = "TI OMAP5 uEVM board";
> > @@ -254,6 +256,171 @@
> > pinctrl-0 = <&i2c1_pins>;
> >
> > clock-frequency = <40>;
> > +
> > + palmas: palmas@48 {
> > + compatible = "ti,palmas";
> > + interrupts = ; /* 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;
> > + };
> > +
> &
[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
---
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
#include
-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
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
[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
---
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[PALM
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
> Signed-off-by: J Keerthy
> Reviewed-by: Stephen Warren
> ---
> 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
> +#include
>
> / {
> model = "TI OMAP5 uEVM board";
> @@ -254,6 +256,171 @@
> pinctrl-0 = <&i2c1_pins>;
>
> clock-frequency = <40>;
> +
> + palmas: palmas@48 {
> + compatible = "ti,palmas";
> + interrupts = ; /* 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 {
>
[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
Signed-off-by: J Keerthy
Reviewed-by: Stephen Warren
---
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
+#include
/ {
model = "TI OMAP5 uEVM board";
@@ -254,6 +256,171 @@
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ palmas: palmas@48 {
+ compatible = "ti,palmas";
+ interrupts = ; /* 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 {
+
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
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 = ; /* 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 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
Signed-off-by: J Keerthy
---
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
+#include
/ {
model = "TI OMAP5 uEVM board";
@@ -254,6 +256,171 @@
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ palmas: palmas@48 {
+ reg = <0x48>;
+ interrupts = ; /* 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"
[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
Signed-off-by: J Keerthy
---
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
+#include
/ {
model = "TI OMAP5 uEVM board";
@@ -254,6 +256,171 @@
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ palmas: palmas@48 {
+ reg = <0x48>;
+ interrupts = ; /* 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 =
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 = ; /* 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 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
Signed-off-by: J Keerthy
---
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
+#include
/ {
model = "TI OMAP5 uEVM board";
@@ -254,6 +256,174 @@
pinctrl-0 = <&i2c1_pins>;
clock-frequency = <40>;
+
+ palmas: palmas@48 {
+ reg = <0x48>;
+ interrupts = ; /* 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;
+
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
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 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
> > ---
> > 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
> > +#include
> >
> > / {
> > 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 = ; /* 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 = &l
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 > > Signed-off-by: J Keerthy > > --- > > 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
[PATCH v2 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory
Signed-off-by: J Keerthy
---
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
+
+&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 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
---
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
+#include
/ {
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 = ; /* 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;
+ regulato
[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
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
> > ---
> > 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 = <
[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
[PATCH 1/2] ARM: dts: add dtsi for palmas
Adds palmas mfd and palmas regulator nodes.
Signed-off-by: Graeme Gregory
Signed-off-by: J Keerthy
---
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
+
+&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 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
---
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>;
+ regula
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
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
> Signed-off-by: Graeme Gregory
> ---
> 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
> +
> +&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>;
> +
[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
Signed-off-by: Graeme Gregory
---
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
+
+&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;
+
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"
> > >> Cc: Santosh Shilimkar
> > >> Cc: Shawn Guo
> > >> 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
> > >> ---
> > > 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(v
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
> -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 > > 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-omap&m=136070089529743&w=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: 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 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 Cc: Benoît Cousson Cc: Mike Turquette > > - 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: 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
> -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: 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
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 > Reviewed-by: Rajendra Nayak > Cc: Paul Walmsley > Cc: Eduardo Valentin 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 > Reviewed-by: Rajendra Nayak > Cc: Paul Walmsley > Cc: Eduardo Valentin 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
Reviewed-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Eduardo Valentin
---
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,
[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
Reviewed-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Eduardo Valentin
---
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
[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
Reviewed-by: Rajendra Nayak
Cc: Paul Walmsley
Cc: Eduardo Valentin
---
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
Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Fri, Jun 1, 2012 at 4:10 AM, Kevin Hilman wrote: > Kevin Hilman writes: > >> "J, KEERTHY" writes: >> >>> On Tue, May 15, 2012 at 11:16 AM, J, KEERTHY wrote: >>>> On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman wrote: >>>>> Rafael, >>>>> >>>>> Keerthy writes: >>>>> >>>>>> From: J Keerthy >>>>>> >>>>>> 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 wrote: > On Tue, May 8, 2012 at 5:21 AM, Kevin Hilman wrote: >> Rafael, >> >> Keerthy writes: >> >>> From: J Keerthy >>> >>> 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 wrote: > Rafael, > > Keerthy writes: > >> From: J Keerthy >> >> 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 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 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
>>
>> 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
>> Signed-off-by: J Keerthy
>> Cc: Paul Walmsley
>> Cc: Thara Gopinath
>> Cc: Nishanth Menon
>> Cc: Kevin Hilman
>> ---
>> 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, NVALUERECIP
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 wrote:
> On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
>> On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata wrote:
>> > On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
>> >> From: Jean Pihet
>> >>
>> >> 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
>> >> Signed-off-by: J Keerthy
>> >> ---
>> >> 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
>> >> #include
>> >> -
>> >> +#include
>> >> #include
>> >>
>> >> /*
>> >> @@ -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 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman wrote: > "AnilKumar, Chimata" writes: > >> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: >>> Hi Mark, >>> >>> Mark Brown 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 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
On Tue, May 8, 2012 at 5:25 AM, Kevin Hilman wrote:
> Kevin Hilman writes:
>
>> "J, KEERTHY" 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 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata wrote:
> On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
>> From: Jean Pihet
>>
>> 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
>> Signed-off-by: J Keerthy
>> ---
>> 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
>> #include
>> -
>> +#include
>> #include
>>
>> /*
>> @@ -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 wrote:
> On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
>> From: Jean Pihet
>>
>> Change the name field value to better reflect the smartreflex
>> integration in the system.
>>
>> Signed-off-by: Jean Pihet
>> Signed-off-by: J Keerthy
>> ---
>> 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 wrote: > On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman wrote: >> Mark Brown writes: >> >>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>>> Mark Brown 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 wrote: > Mark Brown writes: > >> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote: >>> Mark Brown 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 wrote: > Hi Mark, > > Mark Brown 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 wrote: > On Thu, Apr 26, 2012 at 11:10:31PM +0530, Keerthy wrote: >> From: J Keerthy >> >> 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 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
5430 adc to temp
-- Regards and Thanks, Keerthy -36400, -36000, -35600, -35200, -34800, -34300, -33800, -33400, -33000, -32600, -32200, -31800, -31300, -30800, -30400, -3, -29600, -29200, -28700, -28200, -27800, -27400, -27000, -26600, -26200, -25700, -25200, -24800, -24400, -24000, -23600, -23200, -22700, -22200, -21800, -21400, -21000, -20600, -20200, -19700, -19200, -9300, -18400, -18000, -17600, -17200, -16700, -16200, -15800, -15400, -15000, -14600, -14200, -13700, -13200, -12800, -12400, -12000, -11600, -11200, -10700, -10200, -9800, -9400, -9000, -8600, -8200, -7700, -7200, -6800, -6400, -6000, -5600, -5200, -4800, -4300, -3800, -3400, -3000, -2600, -2200, -1800, -1300, -800, -400, 0, 400, 800, 1200, 1600, 2100, 2600, 3000, 3400, 3800, 4200, 4600, 5100, 5600, 6000, 6400, 6800, 7200, 7600, 8000, 8500, 9000, 9400, 9800, 10200, 10800, 11100, 11400, 11900, 12400, 12800, 13200, 13600, 14000, 14400, 14800, 15300, 15800, 16200, 16600, 17000, 17400, 17800, 18200, 18700, 19200, 19600, 2, 20400, 20800, 21200, 21600, 22100, 22600, 23000, 23400, 23800, 24200, 24600, 25000, 25400, 25900, 26400, 26800, 27200, 27600, 28000, 28400, 28800, 29300, 29800, 30200, 30600, 31000, 31400, 31800, 32200, 32600, 33100, 33600, 34000, 34400, 34800, 35200, 35600, 36000, 36400, 36800, 37300, 37800, 38200, 38600, 39000, 39400, 39800, 40200, 40600, 41100, 41600, 42000, 42400, 42800, 43200, 43600, 44000, 44400, 44800, 45300, 45800, 46200, 46600, 47000, 47400, 47800, 48200, 48600, 49000, 49500, 5, 50400, 50800, 51200, 51600, 52000, 52400, 52800, 53200, 53700, 54200, 54600, 55000, 55400, 55800, 56200, 56600, 57000, 57400, 57800, 58200, 58700, 59200, 59600, 6, 60400, 60800, 61200, 61600, 62000, 62400, 62800, 63300, 63800, 64200, 64600, 65000, 65400, 65800, 66200, 66600, 67000, 67400, 67800, 68200, 68700, 69200, 69600, 7, 70400, 70800, 71200, 71600, 72000, 72400, 72800, 73200, 73600, 74100, 74600, 75000, 75400, 75800, 76200, 76600, 77000, 77400, 77800, 78200, 78600, 79000, 79400, 79800, 80300, 80800, 81200, 81600, 82000, 82400, 82800, 83200, 83600, 84000, 84400, 84800, 85200, 85600, 86000, 86400, 86800, 87300, 87800, 88200, 88600, 89000, 89400, 89800, 90200, 90600, 91000, 91400, 91800, 92200, 92600, 93000, 93400, 93800, 94200, 94600, 95000, 95500, 96000, 96400, 96800, 97200, 97600, 98000, 98400, 98800, 99200, 99600, 10, 100400, 100800, 101200, 101600, 102000, 102400, 102800, 103200, 103600, 104000, 104400, 104800, 105200, 105600, 106100, 106600, 107000, 107400, 107800, 108200, 108600, 109000, 109400, 109800, 110200, 110600, 111000, 111400, 111800, 112200, 112600, 113000, 113400, 113800, 114200, 114600, 115000, 115400, 115800, 116200, 116600, 117000, 117400, 117800, 118200, 118600, 119000, 119400, 119800, 120200, 120600, 121000, 121400, 121800, 122200, 122600, 123000, 123400, 123800, 124200, 124600, 124900, 125000, 125000, 125000, 125000,
Re: [PATCH] mfd: OMAP4460+: System control module driver
On Fri, Sep 23, 2011 at 12:20 PM, Paul Walmsley 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 >> 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 >> + * Author: Moiz Sonasath >> + * >> + * 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
Re: [PATCH 3/6] OMAP4460: Temperature sensor data
On Sat, Sep 24, 2011 at 1:18 PM, Paul Walmsley wrote: > On Fri, 23 Sep 2011, J, KEERTHY wrote: > >> On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley 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 >> >> + * >> >> + * 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 wrote: > On Fri, 23 Sep 2011, J, KEERTHY wrote: > >> On Fri, Sep 23, 2011 at 11:33 AM, Paul Walmsley 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 4/6] OMAP4: Hwmod: system control module hwmod
On Fri, Sep 23, 2011 at 11:45 AM, Paul Walmsley wrote: > + Benoît > > Hi, > > On Thu, 22 Sep 2011, Keerthy wrote: > >> From: Benoit Cousson >> >> 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 >> Signed-off-by: Keerthy > > > > - 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 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
>> 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
>> + *
>> + * 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
>> +#include "control.h"
>> +#include
>> +
>> +/*
>> + * 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
