Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


khilman at ti

May 8, 2012, 3:16 PM

Post #1 of 6 (102 views)
Permalink
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

"Woodruff, Richard" <r-woodruff2 [at] ti> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


r-woodruff2 at ti

May 8, 2012, 5:39 PM

Post #2 of 6 (101 views)
Permalink
RE: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


koen at dominion

May 9, 2012, 1:19 AM

Post #3 of 6 (96 views)
Permalink
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

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--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


khilman at ti

May 9, 2012, 11:29 AM

Post #4 of 6 (95 views)
Permalink
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

"Woodruff, Richard" <r-woodruff2 [at] ti> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


nm at ti

May 23, 2012, 6:27 AM

Post #5 of 6 (95 views)
Permalink
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <khilman [at] ti> wrote:
> "Woodruff, Richard" <r-woodruff2 [at] ti> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


khilman at ti

May 24, 2012, 4:16 PM

Post #6 of 6 (91 views)
Permalink
Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling) [In reply to]

"Menon, Nishanth" <nm [at] ti> writes:

> On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman <khilman [at] ti> wrote:
>> "Woodruff, Richard" <r-woodruff2 [at] ti> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.