Quoting Rajendra Nayak (2018-12-20 20:52:34)
>
> On 12/21/2018 2:59 AM, Stephen Boyd wrote:
> > Quoting Rob Herring (2018-12-19 15:47:25)
> >> On Wed, Dec 19, 2018 at 4:40 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >>> On Wed, Dec 19, 2018 at 12:40 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >>>> On Wed, Dec 19, 2018 at 12:09 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> >>>> ...but it does have a frequency, doesn't it?
> >>>>
> >>>> + compatible = "operating-points-v2-qcom-level";
> >>>> +
> >>>> + opp-710000000 {
> >>>> + opp-hz = /bits/ 64 <710000000>;
> >>>> + qcom,level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
> >>>> + };
> >>>
> >>> Ah, I perhaps see the confusion. So Rajendra's usage of
> >>> "operating-points-v2-qcom-level" [1] doesn't have a frequency but
> >>> Jordan's do. So I guess it makes sense that Jordan's have the
> >>> fallback compatible but Rajendra's don't?
> >>
> >> Is having it useful to s/w that doesn't understand
> >> "operating-points-v2-qcom-level"? If so, then add
> >> "operating-points-v2". If not, then don't.
> >
> > The only benefit I see in having "operating-points-v2" is that we don't
> > need to update the of_skipped_node_table[] in drivers/platform/of.c to
> > have all the variants of operating-points-v2-* when they decide to not
> > use anything from the "base" binding.
> >
> > If that fails to work because opp-hz is required for the
> > "operating-points-v2" binding but sometimes
> > operating-points-v2-qcom-level doesn't require it I guess we need to
> > update the skip table or make some generic property like
> > 'this-is-not-a-device' that these various data tables in DT can be
> > marked with so we don't make platform devices for them.
> >
> > Regardless of the above, we should update the binding for
> > operating-points-v2-qcom-level to say that opp-hz isn't always required
> > when the qcom-level compatible is present. It looks like it just says
> > that it builds on top of the opp binding so that's not obvious.
>
> Sure, I can respin with those details added in.
Ok.
> So I am guessing the conclusion is to use a fallback "operating-points-v2"
> compatible *only* when we do have opp-hz along with qcom,level (as in the
> case with gpu) and not have a fallback compatible in cases when we don't
> have opp-hz (as in the case of rpm power domains)?
> That seems a little inconsistent, and given Rob said either way is fine,
> just do one way or the other and not both, I am inclined to think we should
> just have a "operating-points-v2-qcom-level" and no fallback compatible.
> Does that make sense?
>
Are you going to update the skip table to not create platform devices?
Or introduce some generic property to indicate that this is just data
and not a device node?
