Re: [PATCH v2 1/3] PM: Introduce DEVFREQ: generic DVFS framework withdevice-specific OPPs
From: MyungJoo Ham
Date: Fri May 20 2011 - 01:36:49 EST
On Thu, May 19, 2011 at 5:02 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> On Wednesday, May 18, 2011, MyungJoo Ham wrote:
>> 2011/5/18 Rafael J. Wysocki <rjw@xxxxxxx>:
>> > Hi,
>> Umm... yeah.. that option (calling devfreq_remove_device() for errors)
>> is also possible, which will also remove the need for the macro you've
>> However, when the error is temporary or the device has blocked
>> changing frequencies temporarily from target callback or governor, it
>> could be not so desirable.
> I guess we need some experience here. Namely, it's difficult to say
> what's going to be more frequent, devices that have temporary failures
> or such that either work or not work at all.
> That said, I think the simpler approach is to drop devices from the list
> on errors (perhaps depending on the type of the error).
>> So, I'm considering to call devfreq_remove_device() at error if the
>> error is not "EAGAIN". That will also remove the need for the macro
>> and debug messages above. How about that?
> Sounds reasonable.
Alright, I'll try this in the next revision.
>> >> @@ -225,3 +225,28 @@ config PM_OPP
>> >> representing individual voltage domains and provides SOC
>> >> implementations a ready to use framework to manage OPPs.
>> >> For more information, read <file:Documentation/power/opp.txt>
>> >> +
>> >> +config PM_DEVFREQ
>> >> + bool "Generic Dynamic Voltage and Frequency Scaling (DVFS) Framework"
>> >> + depends on PM_OPP
>> > This assumes the user will know if his/her platform uses that code.
>> > It may be a good idea to make it depend on a user-invisible option that
>> > can be selected by the platform.
>> I think that like CPUFREQ, users will want to enable and disable
>> DEVFREQ feature by choice although they cannot choose the governor
>> directly. I'm also considering to allow users to set governors
>> forcibly and globally at menuconfig (like CPUFREQ does). With CPUFREQ,
>> such options helped a lot in troubleshooting of CPU related issues.
>> Do you think it'd be better to have DEVFREQ enabled unconditionally
>> (if PM_OPP is available) nonetheless?
> First off, it doesn't make sense to enable it if the platform is not going to
> use it. That's why I think it should depend on a platform-selected option.
> Only if that option is set the user should be given the choice to select
> Second, I'm not sure if that's a good idea to force DEVFREQ is the platform
> is going to use it. Perhaps in the future if there are no major issues with
> it, we can do that.
I'll open an option to enable/diable DEVFREQ and will make it depends
on OPP and add platform-selected option like OPP does.
Cheers! It's Friday :)
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/