Hi Viresh, On 05/12/2015 12:16 AM, Viresh Kumar wrote: [..] > On 10-05-15, 20:02, Nishanth Menon wrote: >> On 04/30/2015 07:07 AM, Viresh Kumar wrote: One additional comment - after re-reading the bindings again.. > > +- opp-microvolt: voltage in micro Volts. It can contain entries for multiple > + regulators. > + > + A single regulator's voltage is specified with an array of size one or three. > + Single entry is for target voltage and three entries are for <target min max> > + voltages. Just curious -> is'nt it better to just have min<->max range? binding as it stands right now is open to interpretation as to what will be attempted and in what sequence? with a valid min, target or max - is'nt it more power efficient always to go for a "min" than a target? Further, min<->max implies anywhere in that range and is more consistent with "regulator like" description. >> 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. True. one option might be to allow for vendor specific property extensions - that will let vendors add in additional quirky data custom to their SoCs as needed. > >>> +- 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. Sorry about that. I had kind of expected all bindings to be a single patch :).. > >> 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. > missed this as well :( -- Regards, Nishanth Menon -- 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
