Message-ID: <BANLkTi=Bf0A14iDEyYBtJNOYnSuUjmsFyw@mail.gmail.com>
Date:	Fri, 20 May 2011 14:36:43 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Mark Brown <broonie@...ena.org.uk>,
	Jiejing Zhang <kzjeef@...il.com>, Pavel Machek <pavel@....cz>,
	Colin Cross <ccross@...gle.com>, Nishanth Menon <nm@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <len.brown@...el.com>,
	Kyungmin Park <kyungmin.park@...sung.com>
Subject: Re: [PATCH v2 1/3] PM: Introduce DEVFREQ: generic DVFS framework with
 device-specific OPPs

Hello,

On Thu, May 19, 2011 at 5:02 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Wednesday, May 18, 2011, MyungJoo Ham wrote:
>> 2011/5/18 Rafael J. Wysocki <rjw@...k.pl>:
>> > 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
> DEVFREQ.
>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists