[PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes

[Stephen Boyd]

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 at chromium.org> wrote:
> >>> On Wed, Dec 19, 2018 at 12:40 PM Doug Anderson <dianders at chromium.org> wrote:
> >>>> On Wed, Dec 19, 2018 at 12:09 PM Rob Herring <robh at kernel.org> 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?