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