On Thu, May 21, 2015 at 12:46 AM, Viresh Kumar [off-list ref] wrote:

On 21-05-15, 00:27, Nishanth Menon wrote:

quoted

quoted

+This describes the OPPs belonging to a device. This node can have following
+properties:

[...]

quoted

different angle: How about just target-freq-Hz? just drop the "opp"
prefix for properties of an OPP node? No strong feelings here. (some
folks did have variations of a few Hz based on clock tree - example with
a crystal frequency of 19.2MHz you'd probably get 1001MHz exact, with a
26MHz crystal, you'd get 1000MHz -> ofcourse round-rate is supposed to
help with that... but anyways.. why not say we are trying to indicate
target frequency? I do recollect during initial days of OPP
(pre-dt-adoption days) folks did complain about this - we kinda worked
around this with round-rated handling - but we might as well anticipate it.

Rob suggested opp- prefix and it looks good to me, lets see what
others have to say :)

You can decide the color of the bike shed.

quoted

Thanks for adding the examples - My customer support team especially
will appreciate having such examples ;).

I can understand that :)

quoted

I agree with Mike[1] here -> why not move clocks and supply to cpu0_opp?
"
It seems wrong to me that the clock and supply data is owned by the cpu
node, and not the opp descriptor. Everything about the opp transition
should belong to a provider node. Then the cpu simply needs to consume
that via a phandle.
"

I am not sure if we discussed that point further OR if we kinda got
hooked on to the "should it be in kernel" point of debate in V4.

I did send a reply to that, but no one replied after that. Probably
you want to reply on that ?

Clock and regulator bindings describe connections in the h/w. OPPs are
not a h/w block, but rather properties of the h/w. The connections
here are to the cpu's.

Rob