lkml.org 
[lkml]   [2015]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding
    On 10/30, Viresh Kumar wrote:
    > + opp_table {
    > + compatible = "operating-points-v2";
    > + status = "okay";
    > + opp-shared;
    > +
    > + opp00 {

    A side-note. I wonder if it would be better style to have the
    node name be:

    opp@600000000 {

    At least it seems that the assumption is we can store all the
    possible combinations of OPP values for a particular frequency in
    the same node. Following this style would make dt compilation
    fail if two nodes have the same frequency.

    Also, this makes it sound like opp-supported-hw is really just
    telling us if this is a supported frequency or not for the
    particular device we're running on. The current wording makes it
    sound like we could have two OPP nodes with the same frequency
    but different voltages inside them, which we're trying to
    discourage by compressing the tables into less nodes.

    I think in Lee's case we're only going to use the cuts parameter
    to figure out if the OPP is supported or not. On qcom platforms
    we will only use one parameter for this property as well, the
    speed bin. The slow/fast and version stuff will be handled by
    named opp properties.

    > + /*
    > + * Supports all substrate and process versions for 0xF
    > + * cuts, i.e. only first four cuts.
    > + */
    > + opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>
    > + opp-hz = /bits/ 64 <600000000>;
    > + opp-microvolt = <900000 915000 925000>;

    --
    Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
    a Linux Foundation Collaborative Project


    \
     
     \ /
      Last update: 2015-10-30 23:41    [W:4.332 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site