Quoting Rajendra Nayak (2019-01-03 00:45:53) > > On 12/29/2018 6:59 AM, Stephen Boyd wrote: > >> 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? > > Is any of it really needed, given the bindings specify that the OPP table > should actually be a child node of the device/power domain supporting > it? I don't see who would end up creating platform devices for them. > Good point. If it's a child node then almost all the time we won't be trying to populate the OPP node as another platform device so this isn't really important to handle until that happens, which is probably never.
