Quoting Doug Anderson (2018-12-17 16:34:31)
> Hi,
>
> On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> >
> > +Rob +Stephen,
> >
> > On 14-12-18, 09:04, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> > > >
> > > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > > + gpu_opp_table: opp-table {
> > > > > + compatible = "operating-points-v2-qcom-level";
> > > >
> > > > I think you need to mention "operating-points-v2" as well here.
> > >
> > > Are you saying the above should be:
> > > compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> > >
> > > If so I'm not sure I agree.
> >
> > Well I have my doubts as well on this. This is where the ordering was discussed
> > earlier:
> >
> > https://lore.kernel.org/lkml/152328979897.180276.15963925877442657158@xxxxxxxxxxxxxxxxxxxxxxxxxx/
> >
> > @Rob/Stephen: Should the opp-table node above also have "operating-points-v2"
> > string in the compatible property ?
> >
> > > It's _not_ really compatible with the
> > > "operating-points-v2" binding. If you had a driver that had never
> > > heard of "operating-points-v2-qcom-level" and had only heard of
> > > "operating-points-v2" and it took a look at this node it would have no
> > > idea what to do with it.
> >
> > Well it will parse everything apart from the qcom,level thing, so it can
> > actually parse stuff here.
> >
> > > I'll also note that other instances posted to the list don't list both:
> > >
> > > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for sdm845
> > >
> > > The bindings patch also makes no mention of needing
> > > "operating-points-v2". I think the common case when a fallback is
> > > required it is explicitly called out in the bindings:
> > >
> > > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
> >
> > Sure, maybe I am wrong but its better to get some clarity on it from Rob/Stephen.
>
> In case it helps:
>
> https://lkml.kernel.org/r/20181217210849.GA15490@bogus
>
> ...shows Rob giving a Reviewed-by with just
>
> compatible = "operating-points-v2-qcom-level";
>
> ...and not:
>
> compatible = "operating-points-v2-qcom-level", "operating-points-v2";
>
I don't see a problem if both compatible strings are there. Does that
change anything? I suppose the platform bus populate code won't create a
device for the subnode if it has 'operating-points-v2', so maybe the
fallback compatible string should be there? And then the generic OPP
code can parse out the frequency at least without having to know that
it's a qcom specific OPP table.
