omap3: pm: AVS enabled by default?

omap3: pm: AVS enabled by default?

[Andrew Murray]

Hello,

I noticed that Smart Reflex AVS is not turned on by default - and must
be manually enabled from user-land through the sr_vddX_autocomp
controls.

Are there any plans to enable this by default, or perhaps via a KConfig
option in the future?

I ask because the longer a boot time, the longer the device is running
without AVS (assuming it's not enabled by a boot loader) - and on a
mobile device with frequent power on/offs this duration could add up
leading to a potential missed power saving? I appreciate the saving may
be small - but would it be worthwhile?

Thanks,

Andrew Murray

RE: omap3: pm: AVS enabled by default?

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Andrew Murray
> Sent: Thursday, January 28, 2010 7:53 PM
> To: linux-omap@vger.kernel.org
> Subject: omap3: pm: AVS enabled by default?
> 
> Hello,
> 
> I noticed that Smart Reflex AVS is not turned on by default - and must
> be manually enabled from user-land through the sr_vddX_autocomp
> controls.
> 
> Are there any plans to enable this by default, or perhaps via 
> a KConfig
> option in the future?
> 
> I ask because the longer a boot time, the longer the device is running
> without AVS (assuming it's not enabled by a boot loader) - and on a
> mobile device with frequent power on/offs this duration could add up
> leading to a potential missed power saving? I appreciate the 
> saving may
> be small - but would it be worthwhile?

Andrew,

Some of the initial silicon revisions did not have the efuse data to
Required for AVS. I believe AVS is disabled - by default - to ensure
compatibility with these devices.

Best regards,
Sanjeev

> 
> Thanks,
> 
> Andrew Murray
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: omap3: pm: AVS enabled by default?

[Nishanth Menon]

Premi, Sanjeev had written, on 01/28/2010 09:21 AM, the following:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org 
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Andrew Murray
>> Sent: Thursday, January 28, 2010 7:53 PM
>> To: linux-omap@vger.kernel.org
>> Subject: omap3: pm: AVS enabled by default?
>>
>> Hello,
>>
>> I noticed that Smart Reflex AVS is not turned on by default - and must
>> be manually enabled from user-land through the sr_vddX_autocomp
>> controls.
>>
>> Are there any plans to enable this by default, or perhaps via 
>> a KConfig
>> option in the future?
>>
>> I ask because the longer a boot time, the longer the device is running
>> without AVS (assuming it's not enabled by a boot loader) - and on a
>> mobile device with frequent power on/offs this duration could add up
>> leading to a potential missed power saving? I appreciate the 
>> saving may
>> be small - but would it be worthwhile?
you may want to consider upstart and move most of your drivers into 
modules rather than a static binary ;)

But your point is valid, some folks prefer to have AVS disabled in the 
system during boot  for couple of reasons I know of:
a) during system boot, OMAP is busy, avs comes into play during 
late_init and not early_init as it needs pm configurations, pmic setup 
all other stuff to be done.. so the delay between late_init and 
completion of boot is pretty minimal
b) few folks would like to start the boot without avs and enable it from 
userspace applications to allow debug of issues when avs is enabled 
(even if avs is enabled during that little time it is on.. they'd want 
to avoid it)..

> Some of the initial silicon revisions did not have the efuse data to
> Required for AVS. I believe AVS is disabled - by default - to ensure
> compatibility with these devices.
this should not be a problem - SR driver is smart and will look at it's 
data structures and say - oh, this device does not have efuse, so it 
will crib back saying - good try - but sorry, I cant enable avs at this 
OPP frequency because I dont have efuse data to program the SR AVS module..


All said and done, there are configurations which enable avs by default 
at boot - the corresponding variable is initialized as one in thier 
private trees..

-- 
Regards,
Nishanth Menon

Re: omap3: pm: AVS enabled by default?

[Kevin Hilman]

Nishanth Menon <nm@ti.com> writes:

> Premi, Sanjeev had written, on 01/28/2010 09:21 AM, the following:
>>> -----Original Message-----
>>> From: linux-omap-owner@vger.kernel.org
>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Andrew
>>> Murray
>>> Sent: Thursday, January 28, 2010 7:53 PM
>>> To: linux-omap@vger.kernel.org
>>> Subject: omap3: pm: AVS enabled by default?
>>>
>>> Hello,
>>>
>>> I noticed that Smart Reflex AVS is not turned on by default - and must
>>> be manually enabled from user-land through the sr_vddX_autocomp
>>> controls.
>>>
>>> Are there any plans to enable this by default, or perhaps via a
>>> KConfig
>>> option in the future?
>>>
>>> I ask because the longer a boot time, the longer the device is running
>>> without AVS (assuming it's not enabled by a boot loader) - and on a
>>> mobile device with frequent power on/offs this duration could add up
>>> leading to a potential missed power saving? I appreciate the saving
>>> may
>>> be small - but would it be worthwhile?
> you may want to consider upstart and move most of your drivers into
> modules rather than a static binary ;)
>
> But your point is valid, some folks prefer to have AVS disabled in the
> system during boot  for couple of reasons I know of:
> a) during system boot, OMAP is busy, avs comes into play during
> late_init and not early_init as it needs pm configurations, pmic setup
> all other stuff to be done.. so the delay between late_init and
> completion of boot is pretty minimal
> b) few folks would like to start the boot without avs and enable it
> from userspace applications to allow debug of issues when avs is
> enabled (even if avs is enabled during that little time it is
> on.. they'd want to avoid it)..
>
>> Some of the initial silicon revisions did not have the efuse data to
>> Required for AVS. I believe AVS is disabled - by default - to ensure
>> compatibility with these devices.
> this should not be a problem - SR driver is smart and will look at
> it's data structures and say - oh, this device does not have efuse, so
> it will crib back saying - good try - but sorry, I cant enable avs at
> this OPP frequency because I dont have efuse data to program the SR
> AVS module..
>
>
> All said and done, there are configurations which enable avs by
> default at boot - the corresponding variable is initialized as one in
> thier private trees..

We should probably consider having the SR enable/disable default as
an option availble to platform code.

As part of the SR rewrite, Thara has converted this to a stadard
platform_device/platform_driver model so should be easier then.

Kevin