All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
@ 2013-09-11 12:58 ` Laxman Dewangan
  0 siblings, 0 replies; 8+ messages in thread
From: Laxman Dewangan @ 2013-09-11 12:58 UTC (permalink / raw)
  To: broonie
  Cc: rob.herring, mark.rutland, swarren, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood, Laxman Dewangan

The Turn-on time of the regulator depends on the regulator device's
electrical characteristics. Sometimes regulator turn-on time also
depends on the capacitive load on the given platform and it can be
more than the datasheet value.

The driver provides the enable-time as per datasheet.

Add support for configure the enable ramp time through regulator
constraints so that regulator core can take this value for enable
time for that regulator.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
- Change property name to regulator-enable-ramp-delay and add more details
  in DT doc.
- add the valid pointer check for constraints before accessing it.

 .../devicetree/bindings/regulator/regulator.txt    |    3 +++
 drivers/regulator/core.c                           |    2 ++
 drivers/regulator/of_regulator.c                   |    6 ++++++
 include/linux/regulator/machine.h                  |    2 ++
 4 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..1939f61 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -14,6 +14,9 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardwares which support disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-enable-ramp-delay: Turn-on time for regulator(in uSec). This is
+  the time time taken to reach within some proportion of the target voltage
+  from off state.
 
 Deprecated properties:
 - regulator-compatible: If a regulator chip contains multiple
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a01b8b3..5217c19 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1186,6 +1186,8 @@ overflow_err:
 
 static int _regulator_get_enable_time(struct regulator_dev *rdev)
 {
+	if (rdev->constraints && rdev->constraints->enable_time)
+		return rdev->constraints->enable_time;
 	if (!rdev->desc->ops->enable_time)
 		return rdev->desc->enable_time;
 	return rdev->desc->ops->enable_time(rdev);
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7827384..ea4f36f 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -23,6 +23,8 @@ static void of_get_regulation_constraints(struct device_node *np,
 	const __be32 *min_uA, *max_uA, *ramp_delay;
 	struct property *prop;
 	struct regulation_constraints *constraints = &(*init_data)->constraints;
+	int ret;
+	u32 pval;
 
 	constraints->name = of_get_property(np, "regulator-name", NULL);
 
@@ -73,6 +75,10 @@ static void of_get_regulation_constraints(struct device_node *np,
 		else
 			constraints->ramp_disable = true;
 	}
+
+	ret = of_property_read_u32(np, "regulator-enable-ramp-delay", &pval);
+	if (!ret)
+		constraints->enable_time = pval;
 }
 
 /**
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index 999b20c..670d154 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -95,6 +95,7 @@ struct regulator_state {
  * @initial_state: Suspend state to set by default.
  * @initial_mode: Mode to set at startup.
  * @ramp_delay: Time to settle down after voltage change (unit: uV/us)
+ * @enable_time: Turn-on time of the rails (unit: uS)
  */
 struct regulation_constraints {
 
@@ -129,6 +130,7 @@ struct regulation_constraints {
 	unsigned int initial_mode;
 
 	unsigned int ramp_delay;
+	unsigned int enable_time;
 
 	/* constraint flags */
 	unsigned always_on:1;	/* regulator never off when system is on */
-- 
1.7.1.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
@ 2013-09-11 12:58 ` Laxman Dewangan
  0 siblings, 0 replies; 8+ messages in thread
From: Laxman Dewangan @ 2013-09-11 12:58 UTC (permalink / raw)
  To: broonie
  Cc: rob.herring, mark.rutland, swarren, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood, Laxman Dewangan

The Turn-on time of the regulator depends on the regulator device's
electrical characteristics. Sometimes regulator turn-on time also
depends on the capacitive load on the given platform and it can be
more than the datasheet value.

The driver provides the enable-time as per datasheet.

Add support for configure the enable ramp time through regulator
constraints so that regulator core can take this value for enable
time for that regulator.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
Changes from V1:
- Change property name to regulator-enable-ramp-delay and add more details
  in DT doc.
- add the valid pointer check for constraints before accessing it.

 .../devicetree/bindings/regulator/regulator.txt    |    3 +++
 drivers/regulator/core.c                           |    2 ++
 drivers/regulator/of_regulator.c                   |    6 ++++++
 include/linux/regulator/machine.h                  |    2 ++
 4 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..1939f61 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -14,6 +14,9 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardwares which support disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-enable-ramp-delay: Turn-on time for regulator(in uSec). This is
+  the time time taken to reach within some proportion of the target voltage
+  from off state.
 
 Deprecated properties:
 - regulator-compatible: If a regulator chip contains multiple
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index a01b8b3..5217c19 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1186,6 +1186,8 @@ overflow_err:
 
 static int _regulator_get_enable_time(struct regulator_dev *rdev)
 {
+	if (rdev->constraints && rdev->constraints->enable_time)
+		return rdev->constraints->enable_time;
 	if (!rdev->desc->ops->enable_time)
 		return rdev->desc->enable_time;
 	return rdev->desc->ops->enable_time(rdev);
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7827384..ea4f36f 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -23,6 +23,8 @@ static void of_get_regulation_constraints(struct device_node *np,
 	const __be32 *min_uA, *max_uA, *ramp_delay;
 	struct property *prop;
 	struct regulation_constraints *constraints = &(*init_data)->constraints;
+	int ret;
+	u32 pval;
 
 	constraints->name = of_get_property(np, "regulator-name", NULL);
 
@@ -73,6 +75,10 @@ static void of_get_regulation_constraints(struct device_node *np,
 		else
 			constraints->ramp_disable = true;
 	}
+
+	ret = of_property_read_u32(np, "regulator-enable-ramp-delay", &pval);
+	if (!ret)
+		constraints->enable_time = pval;
 }
 
 /**
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index 999b20c..670d154 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -95,6 +95,7 @@ struct regulator_state {
  * @initial_state: Suspend state to set by default.
  * @initial_mode: Mode to set at startup.
  * @ramp_delay: Time to settle down after voltage change (unit: uV/us)
+ * @enable_time: Turn-on time of the rails (unit: uS)
  */
 struct regulation_constraints {
 
@@ -129,6 +130,7 @@ struct regulation_constraints {
 	unsigned int initial_mode;
 
 	unsigned int ramp_delay;
+	unsigned int enable_time;
 
 	/* constraint flags */
 	unsigned always_on:1;	/* regulator never off when system is on */
-- 
1.7.1.1

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 12:58 ` Laxman Dewangan
  (?)
@ 2013-09-11 17:17 ` Stephen Warren
  2013-09-11 17:46   ` Laxman Dewangan
  -1 siblings, 1 reply; 8+ messages in thread
From: Stephen Warren @ 2013-09-11 17:17 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: broonie, rob.herring, mark.rutland, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood

On 09/11/2013 06:58 AM, Laxman Dewangan wrote:
> The Turn-on time of the regulator depends on the regulator device's
> electrical characteristics. Sometimes regulator turn-on time also
> depends on the capacitive load on the given platform and it can be
> more than the datasheet value.
> 
> The driver provides the enable-time as per datasheet.
> 
> Add support for configure the enable ramp time through regulator
> constraints so that regulator core can take this value for enable
> time for that regulator.

> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt

>  - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
>    For hardwares which support disabling ramp rate, it should be explicitly
>    intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
> +- regulator-enable-ramp-delay: Turn-on time for regulator(in uSec). This is
> +  the time time taken to reach within some proportion of the target voltage
> +  from off state.

This is still a bit unclear. What proportion of the target voltage?
There's no mention that this describes the delay due to the
board/environment rather than the delay due to the internal operation of
the regulator itself. How about:

- regulator-enable-ramp-delay: The time taken, in uSec, for the supply
rail to reach the target voltage, plus/minus whatever tolerance the
board design requires, once the regulator output itself has ramped up.
This value is in addition to whatever built-in ramp time is inherent in
the regulator's own internal design or configuration. This property
describes the additional ramp time required due to board design issues
such as trace capacitance and load on the supply.

That's text repeats "additional" a bit, but I think describes the
situation correctly?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 17:17 ` Stephen Warren
@ 2013-09-11 17:46   ` Laxman Dewangan
  2013-09-11 17:46     ` Stephen Warren
  0 siblings, 1 reply; 8+ messages in thread
From: Laxman Dewangan @ 2013-09-11 17:46 UTC (permalink / raw)
  To: Stephen Warren
  Cc: broonie, rob.herring, mark.rutland, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood

On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
> On 09/11/2013 06:58 AM, Laxman Dewangan wrote:
>> The Turn-on time of the regulator depends on the regulator device's
>> electrical characteristics. Sometimes regulator turn-on time also
>> depends on the capacitive load on the given platform and it can be
>> more than the datasheet value.
>>
>> The driver provides the enable-time as per datasheet.
>>
>> Add support for configure the enable ramp time through regulator
>> constraints so that regulator core can take this value for enable
>> time for that regulator.
>> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
>>   - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
>>     For hardwares which support disabling ramp rate, it should be explicitly
>>     intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
>> +- regulator-enable-ramp-delay: Turn-on time for regulator(in uSec). This is
>> +  the time time taken to reach within some proportion of the target voltage
>> +  from off state.
> This is still a bit unclear. What proportion of the target voltage?
> There's no mention that this describes the delay due to the
> board/environment rather than the delay due to the internal operation of
> the regulator itself. How about:
>
> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply
> rail to reach the target voltage, plus/minus whatever tolerance the
> board design requires, once the regulator output itself has ramped up.
> This value is in addition to whatever built-in ramp time is inherent in
> the regulator's own internal design or configuration. This property
> describes the additional ramp time required due to board design issues
> such as trace capacitance and load on the supply.
>
> That's text repeats "additional" a bit, but I think describes the
> situation correctly?

I wanted to provide the absolute delay rather than additional delay on 
top of inherit delay from device.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 17:46   ` Laxman Dewangan
@ 2013-09-11 17:46     ` Stephen Warren
  2013-09-11 18:09       ` Laxman Dewangan
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Warren @ 2013-09-11 17:46 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: broonie, rob.herring, mark.rutland, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood

On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
> On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
>> On 09/11/2013 06:58 AM, Laxman Dewangan wrote:
>>> The Turn-on time of the regulator depends on the regulator device's
>>> electrical characteristics. Sometimes regulator turn-on time also
>>> depends on the capacitive load on the given platform and it can be
>>> more than the datasheet value.
>>>
>>> The driver provides the enable-time as per datasheet.
>>>
>>> Add support for configure the enable ramp time through regulator
>>> constraints so that regulator core can take this value for enable
>>> time for that regulator.
>>> diff --git
>>> a/Documentation/devicetree/bindings/regulator/regulator.txt
>>> b/Documentation/devicetree/bindings/regulator/regulator.txt
>>>   - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
>>>     For hardwares which support disabling ramp rate, it should be
>>> explicitly
>>>     intialised to zero (regulator-ramp-delay = <0>) for disabling
>>> ramp delay.
>>> +- regulator-enable-ramp-delay: Turn-on time for regulator(in uSec).
>>> This is
>>> +  the time time taken to reach within some proportion of the target
>>> voltage
>>> +  from off state.
>> This is still a bit unclear. What proportion of the target voltage?
>> There's no mention that this describes the delay due to the
>> board/environment rather than the delay due to the internal operation of
>> the regulator itself. How about:
>>
>> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply
>> rail to reach the target voltage, plus/minus whatever tolerance the
>> board design requires, once the regulator output itself has ramped up.
>> This value is in addition to whatever built-in ramp time is inherent in
>> the regulator's own internal design or configuration. This property
>> describes the additional ramp time required due to board design issues
>> such as trace capacitance and load on the supply.
>>
>> That's text repeats "additional" a bit, but I think describes the
>> situation correctly?
> 
> I wanted to provide the absolute delay rather than additional delay on
> top of inherit delay from device.

I suppose that either is fine from a DT perspective. But, the regulator
drivers already know their internal delay, so presumably driver code
will have to take the value from DT, and subtract out whatever delay the
driver already embodies, in order to calculate the extra delay required?
Or, if this property is set, does the driver-specified delay just get
ignored?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 18:09       ` Laxman Dewangan
@ 2013-09-11 17:59         ` Stephen Warren
  2013-09-12 10:12           ` Mark Brown
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Warren @ 2013-09-11 17:59 UTC (permalink / raw)
  To: Laxman Dewangan
  Cc: broonie, rob.herring, mark.rutland, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood

On 09/11/2013 12:09 PM, Laxman Dewangan wrote:
> On Wednesday 11 September 2013 11:16 PM, Stephen Warren wrote:
>> On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
>>> On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
>>>> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply
>>>> rail to reach the target voltage, plus/minus whatever tolerance the
>>>> board design requires, once the regulator output itself has ramped up.
>>>> This value is in addition to whatever built-in ramp time is inherent in
>>>> the regulator's own internal design or configuration. This property
>>>> describes the additional ramp time required due to board design issues
>>>> such as trace capacitance and load on the supply.
>>>>
>>>> That's text repeats "additional" a bit, but I think describes the
>>>> situation correctly?
>>> I wanted to provide the absolute delay rather than additional delay on
>>> top of inherit delay from device.
>> I suppose that either is fine from a DT perspective. But, the regulator
>> drivers already know their internal delay, so presumably driver code
>> will have to take the value from DT, and subtract out whatever delay the
>> driver already embodies, in order to calculate the extra delay required?
>> Or, if this property is set, does the driver-specified delay just get
>> ignored?
> 
> Yes, if property is available then driver-specified delay get ignored.
> Delay will be used from dt provided value.

I'm not sure whether I prefer one option or the other. Perhaps Mark can
decide?

That said, what if the internal ramp rate of the regulator itself is
configurable, and can change at run-time. Won't that affect the total
time? If so, having this property represent the additional time might
better allow the total time to be recalculated based on internal
regulator ramp delay changes. Perhaps the additional time varies if the
internal ramp rate varies though, so perhaps it's not worth thinking
about this situation.

I'd suggest the following text if this property represents the total time:

- regulator-enable-ramp-delay: The time taken, in uSec, for the supply
rail to reach the target voltage, plus/minus whatever tolerance the
board design requires. This property describes the total system ramp
time required due to the combination of internal ramping of the
regulator itself, and board design issues such as trace capacitance and
load on the supply.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 17:46     ` Stephen Warren
@ 2013-09-11 18:09       ` Laxman Dewangan
  2013-09-11 17:59         ` Stephen Warren
  0 siblings, 1 reply; 8+ messages in thread
From: Laxman Dewangan @ 2013-09-11 18:09 UTC (permalink / raw)
  To: Stephen Warren
  Cc: broonie, rob.herring, mark.rutland, rob, devicetree, linux-doc,
	linux-kernel, lgirdwood

On Wednesday 11 September 2013 11:16 PM, Stephen Warren wrote:
> On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
>> On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
>>> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply
>>> rail to reach the target voltage, plus/minus whatever tolerance the
>>> board design requires, once the regulator output itself has ramped up.
>>> This value is in addition to whatever built-in ramp time is inherent in
>>> the regulator's own internal design or configuration. This property
>>> describes the additional ramp time required due to board design issues
>>> such as trace capacitance and load on the supply.
>>>
>>> That's text repeats "additional" a bit, but I think describes the
>>> situation correctly?
>> I wanted to provide the absolute delay rather than additional delay on
>> top of inherit delay from device.
> I suppose that either is fine from a DT perspective. But, the regulator
> drivers already know their internal delay, so presumably driver code
> will have to take the value from DT, and subtract out whatever delay the
> driver already embodies, in order to calculate the extra delay required?
> Or, if this property is set, does the driver-specified delay just get
> ignored?

Yes, if property is available then driver-specified delay get ignored. 
Delay will be used from dt provided value.

Thanks,
Laxman



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V2] regulator: core: add support for configuring turn-on time through constraints
  2013-09-11 17:59         ` Stephen Warren
@ 2013-09-12 10:12           ` Mark Brown
  0 siblings, 0 replies; 8+ messages in thread
From: Mark Brown @ 2013-09-12 10:12 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Laxman Dewangan, rob.herring, mark.rutland, rob, devicetree,
	linux-doc, linux-kernel, lgirdwood

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On Wed, Sep 11, 2013 at 11:59:48AM -0600, Stephen Warren wrote:
> On 09/11/2013 12:09 PM, Laxman Dewangan wrote:

> >> I suppose that either is fine from a DT perspective. But, the regulator
> >> drivers already know their internal delay, so presumably driver code
> >> will have to take the value from DT, and subtract out whatever delay the
> >> driver already embodies, in order to calculate the extra delay required?
> >> Or, if this property is set, does the driver-specified delay just get
> >> ignored?

> > Yes, if property is available then driver-specified delay get ignored.
> > Delay will be used from dt provided value.

> I'm not sure whether I prefer one option or the other. Perhaps Mark can
> decide?

The drivers don't implement their own delays, this is already factored
out of them into the framework.  It seems simpler from both a user and
implementation point of view for the delay specified in the DT to just
completely override what the drivers know.

> That said, what if the internal ramp rate of the regulator itself is
> configurable, and can change at run-time. Won't that affect the total
> time? If so, having this property represent the additional time might
> better allow the total time to be recalculated based on internal
> regulator ramp delay changes. Perhaps the additional time varies if the
> internal ramp rate varies though, so perhaps it's not worth thinking
> about this situation.

There's very little use case for varying the ramp rate from cold at run
time - it's mostly just used to limit inrush current on initial power
on.  I think it's OK to just say that if someone specifies a fixed dleay
and varies the ramp rate then they probably aren't being sensible and
get to keep all the pieces.

> - regulator-enable-ramp-delay: The time taken, in uSec, for the supply

microseconds.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-09-12 10:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-11 12:58 [PATCH V2] regulator: core: add support for configuring turn-on time through constraints Laxman Dewangan
2013-09-11 12:58 ` Laxman Dewangan
2013-09-11 17:17 ` Stephen Warren
2013-09-11 17:46   ` Laxman Dewangan
2013-09-11 17:46     ` Stephen Warren
2013-09-11 18:09       ` Laxman Dewangan
2013-09-11 17:59         ` Stephen Warren
2013-09-12 10:12           ` Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.