* Re: Shared regulator usage
2012-11-27 11:15 ` Shared regulator usage Anirudh Ghayal
@ 2012-11-27 11:32 ` Mark Brown
2012-11-27 15:17 ` Kevin Hilman
1 sibling, 0 replies; 3+ messages in thread
From: Mark Brown @ 2012-11-27 11:32 UTC (permalink / raw)
To: Anirudh Ghayal; +Cc: linux-arm-msm, linux-kernel, collinsd, khilman, tsoni
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Shared regulator usage
2012-11-27 11:15 ` Shared regulator usage Anirudh Ghayal
2012-11-27 11:32 ` Mark Brown
@ 2012-11-27 15:17 ` Kevin Hilman
1 sibling, 0 replies; 3+ messages in thread
From: Kevin Hilman @ 2012-11-27 15:17 UTC (permalink / raw)
To: Anirudh Ghayal; +Cc: Mark Brown, linux-arm-msm, linux-kernel, collinsd, tsoni
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
^ permalink raw reply [flat|nested] 3+ messages in thread