On Thu, May 21, 2015 at 12:46 AM, Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 21-05-15, 00:27, Nishanth Menon wrote: >> > +This describes the OPPs belonging to a device. This node can have following >> > +properties: [...] >> 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. > >> Thanks for adding the examples - My customer support team especially >> will appreciate having such examples ;). > > I can understand that :) > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
