On 28/04/17 06:00, Viresh Kumar wrote: > On 27-04-17, 16:20, Rajendra Nayak wrote: >> >> On 04/27/2017 03:12 PM, Sudeep Holla wrote: >> [].. >> >>>> >>>>> At qualcomm, we have an external M3 core (running its own firmware) which controls >>>>> a few voltage rails (including AVS on those). The devices vote for the voltage levels >>> >>> Thanks for explicitly mentioning this, but ... >>> >>>>> (or performance levels) they need by passing an integer value to the M3 (not actual >>> >>> you contradict here, is it just voltage or performance(i.e. frequency) >>> or both ? We need clarity there to choose the right representation. >> >> Its just voltage. > > Right. Its just voltage in this case, but we can't speak of future > platforms here and we have to consider this thing as an operating > performance point only. I still think that this thread is moving in > the right direction, specially after V6 which looks much better. > Just thinking out loud, I can see platforms with have OPPs can move to this binding in future eliminating the need to specify the clock and regulators explicitly. So, I am not saying I against this idea, but I see it might complicate the above case in terms of the precedence that we consider in DT from backward compatibility. E.g. if you now use this for just regulators, then I assume you continue to use clocks. However, that makes it difficult for platforms implementing *real* OPPs to reuse this binding as they may expect to skip clock altogether. Also we may need OPPs(both volt/freq), voltage only and clock only bindings though all 3 are driven by the firmware and all are at abstract levels. I am trying to broaden the scope now without having to churn this binding again in near future. So I don't totally agree that voltage regulators much have *real* voltages and not abstract scale. Yes the correct bindings might have such restrictions but can't we extend it ? Anyways these are just my opinion. > If we have anything strong against the way V6 is trying to solve it, I > want to talk about it right now and get inputs from all the parties > involved. Scrapping all this work is fine, but I would like to do it > ASAP in that case :) > As I said I am not against it, but I see it useful for a different use-case, just not the one you are trying to solve here ;) -- Regards, Sudeep -- 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
