On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <[email protected]> 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.
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.
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
"AnilKumar, Chimata" <[email protected]> writes:
> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>> Hi Mark,
>>
>> Mark Brown <[email protected]> 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/*.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, May 8, 2012 at 5:18 AM, Kevin Hilman <[email protected]> wrote:
> "AnilKumar, Chimata" <[email protected]> writes:
>
>> On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
>>> Hi Mark,
>>>
>>> Mark Brown <[email protected]> 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 [email protected]
>> 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
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote:
> "AnilKumar, Chimata" <[email protected]> writes:
>
> > On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> >> Hi Mark,
> >>
> >> Mark Brown <[email protected]> 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/*.
>
It's perfectly fine with me. My intention was just to highlight that
class 2B SR will have to interact with regulator layer for voltage
changes, so I guess it is little different from other SR classes.
Thanks,
AnilKumar
> > >> The only thing the higher-level layers might potentially need to do
> > >> is 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.)
Getting clean baseline in place is huge step but actual production interfaces will need to comprehend some OPP to AVS dependencies beyond on/off.
AVS as used in many OMAP designs (mostly > OMAP4430) do have some per OPP dependent details:
- Multiple PMICs are in use. In some current designs the AVS step size is different per voltage range. At OPP change time you have to reconfigure several AVS parameters before enable.
- ABB-ldo sequencing and parameters in tightly coupled with OPP and AVS enables.
- Good power savings can be had in future 1.5/3.5 by adjusting nominal to calibrated-plus-margin voltage.
Regards,
Richard W.
"Woodruff, Richard" <[email protected]> writes:
>> > >> The only thing the higher-level layers might potentially need to
>> > >> do is 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.)
>
> Getting clean baseline in place is huge step but actual production
> interfaces will need to comprehend some OPP to AVS dependencies beyond
> on/off.
A basic OMAP AVS driver has been in mainline for a long time, yet we
have not seen support submitted for all of these features.
When folks are motivated to propose such changes upstream, we will be
happy to discuss them and add support for them to the AVS driver.
Until then, the primary purpose of this series is to do some minimal
cleanup of an *existing* driver so it can be moved into drivers/*. New
features can be added there as easily as they could've been added when
it was a driver under arch/arm.
Kevin
> From: Hilman, Kevin
> Sent: Tuesday, May 08, 2012 5:17 PM
> A basic OMAP AVS driver has been in mainline for a long time, yet we
> have not seen support submitted for all of these features.
1.5/3.5 is a feature.
ABB is requirement for a production useable driver. Higher speed rated OMAP4 and all OMAP5 added these to be useable. Yes this is effort. Point of mentioning is to raise awareness of need.
Yet to be added feature has different meaning than functional gap.
Regards,
Richard W.
Op 9 mei 2012, om 02:39 heeft Woodruff, Richard het volgende geschreven:
>> From: Hilman, Kevin
>> Sent: Tuesday, May 08, 2012 5:17 PM
>
>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>> have not seen support submitted for all of these features.
>
> 1.5/3.5 is a feature.
>
> ABB is requirement for a production useable driver.
ABB/FBB is also needed for 1GHz support on omap3 based SoCs like AM37xx and DM37xx.
regards,
Koen-
"Woodruff, Richard" <[email protected]> writes:
>> From: Hilman, Kevin
>> Sent: Tuesday, May 08, 2012 5:17 PM
>
>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>> have not seen support submitted for all of these features.
>
> 1.5/3.5 is a feature.
And I'm still waiting for it to be submitted upstream.
> ABB is requirement for a production useable driver. Higher speed rated
> OMAP4 and all OMAP5 added these to be useable.
ditto
> Yes this is effort. Point of mentioning is to raise awareness of need.
I'm well aware of the need.
> Yet to be added feature has different meaning than functional gap.
And both need to be submitted upstream.
Kevin
On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <[email protected]> wrote:
> "Woodruff, Richard" <[email protected]> writes:
>
>>> From: Hilman, Kevin
>>> Sent: Tuesday, May 08, 2012 5:17 PM
>>
>>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>>> have not seen support submitted for all of these features.
>>
>> 1.5/3.5 is a feature.
>
> And I'm still waiting for it to be submitted upstream.
>
>> ABB is requirement for a production useable driver. Higher speed rated
>> OMAP4 and all OMAP5 added these to be useable.
>
> ditto
>
>> Yes this is effort. Point of mentioning is to raise awareness of need.
>
> I'm well aware of the need.
>
>> Yet to be added feature has different meaning than functional gap.
>
> And both need to be submitted upstream.
SR 1.5: http://marc.info/?l=linux-omap&m=129933897910785&w=2
ABB: http://marc.info/?l=linux-omap&m=130939399209099&w=2
I am not sure what you mean "need to be submitted upstream"?
Just tired of seeing things perpetually change without considering
even how to handle features that are mandatory for SoC even with code
posted upstream to show exactly what it takes.. I think you do mean
merged upstream in this context.
Regards,
Nishanth Menon
"Menon, Nishanth" <[email protected]> writes:
> On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <[email protected]> wrote:
>> "Woodruff, Richard" <[email protected]> writes:
>>
>>>> From: Hilman, Kevin
>>>> Sent: Tuesday, May 08, 2012 5:17 PM
>>>
>>>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>>>> have not seen support submitted for all of these features.
>>>
>>> 1.5/3.5 is a feature.
>>
>> And I'm still waiting for it to be submitted upstream.
>>
>>> ABB is requirement for a production useable driver. Higher speed rated
>>> OMAP4 and all OMAP5 added these to be useable.
>>
>> ditto
>>
>>> Yes this is effort. Point of mentioning is to raise awareness of need.
>>
>> I'm well aware of the need.
>>
>>> Yet to be added feature has different meaning than functional gap.
>>
>> And both need to be submitted upstream.
>
> SR 1.5: http://marc.info/?l=linux-omap&m=129933897910785&w=2
> ABB: http://marc.info/?l=linux-omap&m=130939399209099&w=2
>
> I am not sure what you mean "need to be submitted upstream"?
You're right. I should've said re-submitted and merged. Both have been
submitted (and reviewed) but no follow up submissions after review, and
thus they're still out of tree.
> Just tired of seeing things perpetually change without considering
> even how to handle features that are mandatory for SoC even with code
> posted upstream to show exactly what it takes..
I'm sorry, but this is not perpetual change.
This driver has been upstream in its current (admittedly
feature-limited) form for a long time, the only thing changing in
$SUBJECT series is the location of the driver. Why all the fuss about
the missing features now?
> I think you do mean merged upstream in this context.
Correct.
Frameworks always have limitations. The way they get extended/expanded
etc. is by the submission/review/merging of support for new
features/requirements. The process for that is the same as any feature
in any part of the kernel.
Evolution, not intelligent design[1].
All of that being said, I'm not sure why this thread was hijacked for
this debate in the first place. The point of $SUBJECT series is simply
to move and *existing* framework from arch/arm out to drivers. The only
changes done are cleanups to make this move possible.
I for one would welcome extending this framework to ensure it supports
all the SoC features. I just don't want those features to be a
prerequisite for this move from arch/arm to drivers.
Please, let's get this moved to drivers, and then add support for the
missing features.
Thanks,
Kevin
[1] http://kerneltrap.org/Linux/Kernel_Evolution