lkml.org 
[lkml]   [2014]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
    On 07/07/14 21:50, Viresh Kumar wrote:
    > On 4 July 2014 09:51, Viresh Kumar <viresh.kumar@linaro.org> wrote:
    >> Yeah, having something like what you suggested from DT is the perfect
    >> solution to get over this. The only reason why I am not touching that here
    >> is to not delay other patches just because of that.
    >>
    >> There are separate threads going on for that and probably somebody
    >> else was trying to push for that.
    >>
    >> That's it, nothing more. I would definitely like to use those bindings instead
    >> of the crazy routines we are trying here, once that is finalized :)
    > Do we have some kind of agreement for this temporary solution? Anyways
    > I will kick the other thread again to resolve the bindings soon.
    >
    > @Stephen: Do you still want find_rate_changer() stuff in this series only
    > and or this can go into 3.17 without anymore changes and lets finalize
    > the bindings Mike suggested and then update this code?
    >
    >

    Finding the rate change is not necessary for me. I don't imagine my code
    will be getting into 3.17 anyway though so I'm no in a rush to merge
    anything immediately.

    I still prefer the common clock framework API. If we go ahead with the
    find_rate_changer() stuff we've pretty well insulated this driver from
    any DTisms, which is nice. The only thing left would be
    transition-latency and voltage-tolerance, but those are already optional
    so you really don't need to even run on a DT enabled platform to use
    this code.

    --
    Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
    hosted by The Linux Foundation



    \
     
     \ /
      Last update: 2014-07-09 20:21    [W:2.332 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site