lkml.org 
[lkml]   [2011]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2 1/3] PM: Introduce DEVFREQ: generic DVFS framework with device-specific OPPs
    From
    Hello,

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

    \
     
     \ /
      Last update: 2011-05-20 07:39    [W:2.355 / U:1.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site