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,
> 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
>> mentioned.
> Yes.
>> 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.
> Thanks,
> Rafael

I see.

I'll open an option to enable/diable DEVFREQ and will make it depends
on OPP and add platform-selected option like OPP does.

Thank you.

Cheers! It's Friday :)
- MyungJoo

MyungJoo Ham, Ph.D.
Mobile Software Platform Lab,
Digital Media and Communications (DMC) Business
Samsung Electronics
cell: 82-10-6714-2858
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at