Shared regulator usage

Shared regulator usage

[aghayal]

Hi Mark,

We seem to having a small design problem in our drivers with the usage of
the regulator framework. Kindly let us know your thoughts on this.

On our SoC's, the regulator powering the core can be controlled by two
consumers, the cpu freq. driver and a core power reduction driver (two
independent drivers). Each of them can independently control the core
voltage across 0.9v to 1.5v. The problem arises when each of them executes
a set_voltage call with their recommended voltage. The framework's
regulator_check_consumers() check does not allow both these drivers to set
their required voltage.

For example:
Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The
regulator framework eventually sets the regulator to 1.275v. Consumer (B)
recommends a lower the voltage say (1.25v) and executes set_volatge on
{1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does
not meet the (A)'s constraint.

We are looking for the right way to handle such a situation using
regulator framework, considering this to be a valid usecase. One way we
could think of is having one of the driver (say cpu-freq) register a
virtual regulator device and have the other driver be its consumer. This
way all the regulator calls to the physical hardware will be routed though
one primary driver which can take care of the adjustments. The problem
with such approach would be scalability for a new consumer, i.e. adding
another consumer for the primary driver would present a similar problem as
the original one.

Please let us know if there's a good way of handling such a situation
using the regulator framework.

Thank you,
Anirudh

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--

Re: Shared regulator usage

[Mark Brown]

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

On Mon, Nov 26, 2012 at 05:13:37AM -0800, aghayal@codeaurora.org wrote:

> For example:
> Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The
> regulator framework eventually sets the regulator to 1.275v. Consumer (B)
> recommends a lower the voltage say (1.25v) and executes set_volatge on
> {1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does
> not meet the (A)'s constraint.

Well, of course.  What else would you expect to happen in this case?

> We are looking for the right way to handle such a situation using
> regulator framework, considering this to be a valid usecase. One way we
> could think of is having one of the driver (say cpu-freq) register a
> virtual regulator device and have the other driver be its consumer. This
> way all the regulator calls to the physical hardware will be routed though
> one primary driver which can take care of the adjustments. The problem
> with such approach would be scalability for a new consumer, i.e. adding
> another consumer for the primary driver would present a similar problem as
> the original one.

Why not just fix your consumers to request the voltage ranges they
actually want?  Clearly in your above example one of the consumers can
support a wider voltage range than it is actually requesting so it
should just request that voltage range.

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

Re: Shared regulator usage

[Anirudh Ghayal]

On 11/26/2012 7:17 PM, Mark Brown wrote:
> On Mon, Nov 26, 2012 at 05:13:37AM -0800, aghayal@codeaurora.org wrote:
>
>> For example:
>> Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The
>> regulator framework eventually sets the regulator to 1.275v. Consumer (B)
>> recommends a lower the voltage say (1.25v) and executes set_volatge on
>> {1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does
>> not meet the (A)'s constraint.
>
> Well, of course.  What else would you expect to happen in this case?
>
>> We are looking for the right way to handle such a situation using
>> regulator framework, considering this to be a valid usecase. One way we
>> could think of is having one of the driver (say cpu-freq) register a
>> virtual regulator device and have the other driver be its consumer. This
>> way all the regulator calls to the physical hardware will be routed though
>> one primary driver which can take care of the adjustments. The problem
>> with such approach would be scalability for a new consumer, i.e. adding
>> another consumer for the primary driver would present a similar problem as
>> the original one.
>
> Why not just fix your consumers to request the voltage ranges they
> actually want?  Clearly in your above example one of the consumers can
> support a wider voltage range than it is actually requesting so it
> should just request that voltage range.
>
Mark,

Let me try to explain this further.

Both our cpu-freq and the core-power-reduction (CPR) driver manipulate 
the voltage to the same physical device (apps core) and both these 
drivers are independent. The cpu-freq driver has predefined static 
<frequency, voltage> mappings and accordingly sets the nominal voltage 
based on the target frequency. The CPR then does micro adjustments to 
this voltage making it more optimal to save power. This is very similar 
to the SmartReflex design on the OMAP 
(http://omappedia.org/wiki/SR_Voltage_Control_Migration, 
http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/034117.html), 
the only difference being that in our case both the consumer drivers use 
the regulator framework to manipulate the voltage. I suppose on OMAP 
they handle such a case inside the OMAP-specific voltage layer.

A typical example in our case is --

cpu-freq mappings
<1.4Ghz, 1.3v>
<1.2Ghz, 1.2v>
<1.1Ghz, 1.1v>

At 1.4Ghz the cpu-freq driver votes for 1.3v, then the CPR kicks in and 
recommends a voltage of 1.275v. Now a set_voltage with this new level 
(1.275v, 1.275)  fails as it does not satisfy the limits of the cpu-freq 
driver. It is not possible to tweak this range any further as it would 
not achieve the goal of micro-adjusting the voltage to save power.

Such scenarios are very likely to occur in the future on embedded 
systems where there is a need to conserve power by introducing some 
adaptive voltage scaling techniques based on various parameters such as 
temperature/sensitivity.

Thank you,
~Anirudh

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation.

Re: Shared regulator usage

[Mark Brown]

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

On Tue, Nov 27, 2012 at 04:45:29PM +0530, Anirudh Ghayal wrote:

> At 1.4Ghz the cpu-freq driver votes for 1.3v, then the CPR kicks in
> and recommends a voltage of 1.275v. Now a set_voltage with this new
> level (1.275v, 1.275)  fails as it does not satisfy the limits of
> the cpu-freq driver. It is not possible to tweak this range any
> further as it would not achieve the goal of micro-adjusting the
> voltage to save power.

> Such scenarios are very likely to occur in the future on embedded
> systems where there is a need to conserve power by introducing some
> adaptive voltage scaling techniques based on various parameters such
> as temperature/sensitivity.

This just sounds like bad software design.  You've got two unrelated
drivers setting the same thing without talking to each other even though
the one is trying to adjust the voltage set by the other without
actually knowing the voltage that the other one set.  Why are these
separate drivers?

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

Re: Shared regulator usage

[Kevin Hilman]

Anirudh Ghayal <aghayal@codeaurora.org> writes:

> On 11/26/2012 7:17 PM, Mark Brown wrote:
>> On Mon, Nov 26, 2012 at 05:13:37AM -0800, aghayal@codeaurora.org wrote:
>>
>>> For example:
>>> Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The
>>> regulator framework eventually sets the regulator to 1.275v. Consumer (B)
>>> recommends a lower the voltage say (1.25v) and executes set_volatge on
>>> {1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does
>>> not meet the (A)'s constraint.
>>
>> Well, of course.  What else would you expect to happen in this case?
>>
>>> We are looking for the right way to handle such a situation using
>>> regulator framework, considering this to be a valid usecase. One way we
>>> could think of is having one of the driver (say cpu-freq) register a
>>> virtual regulator device and have the other driver be its consumer. This
>>> way all the regulator calls to the physical hardware will be routed though
>>> one primary driver which can take care of the adjustments. The problem
>>> with such approach would be scalability for a new consumer, i.e. adding
>>> another consumer for the primary driver would present a similar problem as
>>> the original one.
>>
>> Why not just fix your consumers to request the voltage ranges they
>> actually want?  Clearly in your above example one of the consumers can
>> support a wider voltage range than it is actually requesting so it
>> should just request that voltage range.
>>
> Mark,
>
> Let me try to explain this further.
>
> Both our cpu-freq and the core-power-reduction (CPR) driver manipulate
> the voltage to the same physical device (apps core) and both these
> drivers are independent. The cpu-freq driver has predefined static
> <frequency, voltage> mappings and accordingly sets the nominal voltage
> based on the target frequency. The CPR then does micro adjustments to
> this voltage making it more optimal to save power. This is very
> similar to the SmartReflex design on the OMAP
> (http://omappedia.org/wiki/SR_Voltage_Control_Migration,
> http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/034117.html),
> the only difference being that in our case both the consumer drivers
> use the regulator framework to manipulate the voltage. I suppose on
> OMAP they handle such a case inside the OMAP-specific voltage layer.
>
> A typical example in our case is --
>
> cpu-freq mappings
> <1.4Ghz, 1.3v>
> <1.2Ghz, 1.2v>
> <1.1Ghz, 1.1v>
>
> At 1.4Ghz the cpu-freq driver votes for 1.3v, then the CPR kicks in
> and recommends a voltage of 1.275v. Now a set_voltage with this new
> level (1.275v, 1.275)  fails as it does not satisfy the limits of the
> cpu-freq driver. It is not possible to tweak this range any further as
> it would not achieve the goal of micro-adjusting the voltage to save
> power.
>
> Such scenarios are very likely to occur in the future on embedded
> systems where there is a need to conserve power by introducing some
> adaptive voltage scaling techniques based on various parameters such
> as temperature/sensitivity.

FWIW, you're correct about the design on OMAP.

We handle AVS below the regulator framework.  CPUfreq manages "nominal"
voltages, and requests those from the OMAP voltage layer.  If AVS is
enabled, then the voltage layer (actually, the SmartReflex driver)
overrides the nominal voltage with the actual voltage.  

Kevin

Re: Shared regulator usage

[Kevin Hilman]

Anirudh Ghayal <aghayal@codeaurora.org> writes:

> On 11/26/2012 7:17 PM, Mark Brown wrote:
>> On Mon, Nov 26, 2012 at 05:13:37AM -0800, aghayal@codeaurora.org wrote:
>>
>>> For example:
>>> Consumer (A) cpu-freq sets the voltage range to {1.275v, 1.375v}. The
>>> regulator framework eventually sets the regulator to 1.275v. Consumer (B)
>>> recommends a lower the voltage say (1.25v) and executes set_volatge on
>>> {1.25v, 1.25v}. This is where regulator_check_consumers() fails as it does
>>> not meet the (A)'s constraint.
>>
>> Well, of course.  What else would you expect to happen in this case?
>>
>>> We are looking for the right way to handle such a situation using
>>> regulator framework, considering this to be a valid usecase. One way we
>>> could think of is having one of the driver (say cpu-freq) register a
>>> virtual regulator device and have the other driver be its consumer. This
>>> way all the regulator calls to the physical hardware will be routed though
>>> one primary driver which can take care of the adjustments. The problem
>>> with such approach would be scalability for a new consumer, i.e. adding
>>> another consumer for the primary driver would present a similar problem as
>>> the original one.
>>
>> Why not just fix your consumers to request the voltage ranges they
>> actually want?  Clearly in your above example one of the consumers can
>> support a wider voltage range than it is actually requesting so it
>> should just request that voltage range.
>>
> Mark,
>
> Let me try to explain this further.
>
> Both our cpu-freq and the core-power-reduction (CPR) driver manipulate
> the voltage to the same physical device (apps core) and both these
> drivers are independent. The cpu-freq driver has predefined static
> <frequency, voltage> mappings and accordingly sets the nominal voltage
> based on the target frequency. The CPR then does micro adjustments to
> this voltage making it more optimal to save power. This is very
> similar to the SmartReflex design on the OMAP
> (http://omappedia.org/wiki/SR_Voltage_Control_Migration,
> http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/034117.html),
> the only difference being that in our case both the consumer drivers
> use the regulator framework to manipulate the voltage. I suppose on
> OMAP they handle such a case inside the OMAP-specific voltage layer.
>
> A typical example in our case is --
>
> cpu-freq mappings
> <1.4Ghz, 1.3v>
> <1.2Ghz, 1.2v>
> <1.1Ghz, 1.1v>
>
> At 1.4Ghz the cpu-freq driver votes for 1.3v, then the CPR kicks in
> and recommends a voltage of 1.275v. Now a set_voltage with this new
> level (1.275v, 1.275)  fails as it does not satisfy the limits of the
> cpu-freq driver. It is not possible to tweak this range any further as
> it would not achieve the goal of micro-adjusting the voltage to save
> power.
>
> Such scenarios are very likely to occur in the future on embedded
> systems where there is a need to conserve power by introducing some
> adaptive voltage scaling techniques based on various parameters such
> as temperature/sensitivity.

FWIW, you're correct about the design on OMAP.

We handle AVS below the regulator framework.  CPUfreq manages "nominal"
voltages, and requests those from the OMAP voltage layer.  If AVS is
enabled, then the voltage layer (actually, the SmartReflex driver)
overrides the nominal voltage with the actual voltage.  

Kevin