Hi Nishanth, On 10-05-15, 20:02, Nishanth Menon wrote: > On 04/30/2015 07:07 AM, Viresh Kumar wrote: > > +the liberty of choosing these. These triplets are called Operating Performance > > I suggest we dont call them as triplets either -> note, we have added > clk transition latency per OPP, so they are not exactly triplets either. Sure. > > +Points aka OPPs. This document defines bindings for these OPPs applicable across > > +wide range of devices. For illustration purpose, this document uses CPU as a > > +device. > > + > > + > > Would be good to point to operating-points (the legacy document) as > well. It might be good to state that only one of the properties should > be used for the device node OPP description. Hmm, okay. > > +Optional properties: > > +- shared-opp: Indicates that device nodes using this OPP descriptor's phandle > > + switch their DVFS state together, i.e. they share clock/voltage/current lines. > > + Missing property means devices have independent clock/voltage/current lines, > > + but they share OPP tables. > > Is'nt this property redundant? by the fact that phandle is reused for > cpu1 should indicate shared OPP table, correct? There are two things we can share: - OPP tables (And not the clock lines themselves). For example, consider a quad-core platform with independent clock/voltage lines for all CPUs but all the CPUs have same OPP table. - Clock/voltage rails: This is described by the above property. I thought the examples should have made this clear, anything left there ? > > +- turbo-mode: Marks the OPP to be used only for turbo modes. > > Might be great to add some description for what "turbo mode" means here. Okay. > That said, flexibility of this approach is awesome, thanks for doing > this, I believe we did have a discussion about "safe OPP" for thermal > behavior -> now that we have phandles for OPPs, we can give phandle > pointer to the thermal framework. in addition, we can also use phandle > for marking throttling information in thermal framework instead of > indices as well. which allows a lot of flexibility. > > in some systems, we'd have need to mark certain OPPs for entry into > suspend(tegra?) or during shutdown (for example) - do we allow for such > description as phandle pointer back to the OPP nodes (from cpu0 device) > OR do we describe them as additional properties? Haven't thought about it earlier. In case we need them, probably it should go in the OPP table. NOTE: Mike T. once told me that we shouldn't over-abuse the bindings by putting every detail there. And I am not sure at all on how to draw that line. > > +- status: Marks the node enabled/disabled. > > One question we'd probably want the new framework to address is the need > for OPPs based on Efuse options - Am I correct in believing that the > solution that iMX, and TI SoCs probably need is something similar to > modifying the status to disabled? or do we have Vendor specfic modifier > properties that would be allowed? See PATCH 2/3 for that. > One additional behavior need I noticed in various old threads is a need > to restrict transition OPPs -> certain SoCs might have constraints on > next OPP they can transition from certain OPPs in-order to achieve a new > OPP. again, such behavior could be phandle lists OR properties that link > the chain up together. Number of such needs did sound less, but still > just thought to bring it up. See 0/3 and 3/3 for that. Its present in my solution but Mike T. is strictly against keeping that in OPP table. And so 3/3 may get Nak'd. Thanks a lot for your reviews. -- 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
